System and Method for Scheduling Digital Information Transmission and Retransmission on a Network During Time Slots

ABSTRACT

The present invention is a computer system for delivering digital information over a network. A request receiving process receives a request for transmitting digital information after a start time and before an end time. The digital information has a number of packets. A transmit time process determines the time required to transmit the digital information based on the number of packets and a network speed. A scheduler schedules a transmit time for the digital information and an acceptance process accepts the digital information for transmission only if the time required to transmit is less than or equal to the difference between the transmit time and the end time.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of patent application Ser. No.09/649,953, filed Aug. 29, 2000.

FIELD OF THE INVENTION

This invention relates to the field of network communications. Morespecifically, this invention relates to transmission and retransmissionof digital information during specific times. BACKGROUND OF THEINVENTION

With the increased popularity and usage of the Internet and World WideWeb, computers are used to distribute data files (which are often largein size) over digital networks. These data files include electronic mailaddressed to individuals and/or groups of people, postings forelectronic bulletin boards (e.g. the usenet), pages from World Wide Webservers, audio files (encoded with MP3), video files, digital images,digitized books and diagrams, and updates and errata of digitized booksand other documentation. In general, network computing is well known.For example, see U.S. Pat. No. 5,371,852 to Attanasio et al. issued onDec. 6, 1994. This Patent is herein incorporated by reference in itsentirety.

For example, an insurance company may transmit many different forms ofdigital data to their insurance agents. The company may produce trainingvideos and audio tapes which are digitized into video and audio datafiles. It may also publish its rules and regulations in digital form asweb pages or digital books. Updated actuarial tables and insuranceprices may be transmitted periodically. And the insurance company mayuse e-mail to communicate with the agents as a whole or individually.The size of these data files can vary greatly and clearly, some datafiles are more important than others and need to be transmitted at ahigher priority or otherwise in a controlled manner. Currently, much ofthe prior art does not use the priority and size of documents todetermine how the documents are transmitted over a network.

While many techniques and tools are used in scheduling real-time tasksfor computer central processing units (CPUs), these techniques have notbeen applied to scheduling transmissions of data files over a network.In a real-time operating system, a computer has many jobs to run, eachof which has a release time, deadline, worst-case running time, andoptionally a period. The scheduler of the real-time operating systemexamines these job constraints and devises a schedule which allows thecomputers CPU(s) to operate the tasks to completion and meet the releaseand deadline constraints if the constraints taken as a whole arefeasible. Some real-time operating system schedulers also have theability to discard jobs on a priority basis in the event that a feasibleschedule cannot be computed for the entire job set. Two well knownscheduling algorithms for computing a real-time job schedule are theEarliest Deadline First (EDF) algorithm and the Rate Monotonic (RM)algorithm.

STATEMENT OF PROBLEMS WITH THE PRIOR ART

However, CPU scheduling is different than bandwidth scheduling.Bandwidth availability can vary over time—number and speed of CPUprocessors are constant over time. Temporary bursty congestion onnetwork may also slow or choke data transmission. Current TCP/IP filetransmission packages (FTP, HTTP) do not support scheduled pacing andpreemption of data flow. TCP/IP stack and network is available only on a“first come, first served” basis. FTP and HTTP do not have schedulingcapabilities to start sending the file at a given time (they just start“now”).

Further, it would be desirable in some instances, that transmissionsover a digital network be sent with priorities and staggered atdifferent data rates and bursts.

Also, Quality of Service scheduling within routers and switches providesbandwidth constraints either at a packet by packet or cell by celllevel. This scheduling is not applicable to multi-megabyte or gigabytefiles. Queue length and other buffer resources within switches androuters are severely constrained. (In this disclosure, “packet” is usedto describe any sub unit of information transmitted over a network,without the loss of generality.)

In addition, limitations of computer networks include bandwidthconstraints, limited availability of shared bandwidth, networkcongestion, the speed of intermediate network devices (such as routers,switches, bridges, and proxy servers), and data loss to network errors.

The prior art has not adequately addressed delivering information over anetwork during specified time intervals.

The prior art has not been able to apply scheduling or dispatchingtechniques to deal with: priority information; staggered information;quality of service; queue length and buffer constraints; bandwidthconstraints; and information delivery during specific time intervals.Nor has the prior art developed adequate business methods for dealingwith information transmission subject to these constraints over anetwork.

OBJECTS OF THE INVENTION

An object of this invention is an improved system and method forscheduling, dispatching, and/or transmitting information over a network.

An object of this invention is an improved system and method forscheduling, dispatching, and/or transmitting information during specifictime periods over a network.

An object of this invention is an improved system and method forscheduling, dispatching, and/or transmitting information over a networkwith a quality of service.

An object of this invention is an improved system and method forscheduling, dispatching, and/or transmitting information over a networkdespite network constraints.

An object of this invention is an improved system and method forscheduling, dispatching, and/or transmitting information with prioritiesover a network.

SUMMARY OF THE INVENTION

The present invention is a computer system for delivering digitalinformation over a network. A request receiving process receives arequest for transmitting digital information after a start time andbefore an end time. The digital information has a number of packets. Atransmit time process determines the time required to transmit thedigital information based on the number of packets and a network speed.A scheduler schedules a transmit time for the digital information and anacceptance process accepts the digital information for transmission onlyif the time required to transmit is less than or equal to the differencebetween the transmit time and the end time.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, aspects and advantages will be betterunderstood from the following detailed description of preferredembodiments of the invention with reference to the drawings that areinclude the following:

FIG. 1 is a block diagram of a system for requesting and transmittingdata files using the present invention.

FIG. 2 is a block diagram of a transmission decision list which containstransmission criteria which is used by a dispatcher process to determinewhen to transmit data files.

FIG. 3 is a block diagram of a file list which identifies the data filesand is used by a dispatcher process.

FIG. 4 is a block diagram of the history log generated during theexecution of a dispatcher process.

FIG. 5 is a block diagram of the network use criteria table which isused by a dispatcher process.

FIG. 6 is a flow chart of a dispatcher process.

FIG. 6 a is a flow chart of an amount-to-write computation process.

FIG. 7 is a block diagram of a transmission request data structure.

FIG. 7 a is a block diagram of an example transmission request datastructure.

FIG. 8 is a block diagram of the architecture of the scheduler with anoptional estimate transmissions process.

FIG. 9 is a block diagram of one preferred storage filing system.

FIG. 9 a is a block diagram showing sample records in a deliverycriteria list.

FIG. 10 is a flow chart of an estimate transmissions process whichreceives an accepted transmission request and its associated file andcreates records in the delivery criteria list so that the file will betransmitted by the system.

FIG. 11 is a flow chart of a scheduling process using a novel networkuse allocation process.

FIG. 12 is a flow chart of a novel network use allocation process.

FIG. 13 is a flow chart of a feedback process.

FIG. 14 is a flow chart of an acceptance process.

DETAILED DESCRIPTION OF THE INVENTION

FIGS. 1 through 6A, below, describe a dispatch process that is used withthe present invention and is further described and claimed in U.S.patent application Ser. No. 09/649,954, now U.S. Pat. No. 6,959,327,entitled “System and Method for Dispatching and Scheduling NetworkTransmissions with Feedback” to Vogl, et al. which was filed on the sameday as the parent application to the present application, and which isherein incorporated by reference in its entirety as if fully restatedherein.

FIG. 1 is a block diagram of a system 100 containing one or morecomputer network dispatching process 600 (e.g. 600A, 600B). The systemcontains one or more servers (120, 130, and 140) which read informationfrom one or more mass storage devices 110 and transmit the informationover network 159 and/or other transmission means such as aradio/frequency transmitter and/or satellite 150 to one or more clients(160, 170, 180). The network 159 can be any generally known network suchas the Internet, an intra net, the phone network, or atelecommunications network.

Block 120 is a dispatch server which runs the computer networkdispatcher process 600 600A, 600B). This process 600 is described indetail in FIG. 6 below. The dispatch server 120, optionally, runs ascheduler process 128 and a billing process 129. The dispatch server 120has one or more memories 126 which contain a transmission decision list200, a file list 300, a file transmission history log 400, and anoptional network use criteria table 500. These lists (200, 300, 400,500) are described in detail in FIGS. 2, 3, 4, and 5, below,respectively. System time 125 is a clock which provides timinginformation to the dispatch server 120.

Blocks 124A and 124B are network buffers which buffer information to bewritten from the dispatch server 120 to its network connections, 122A,122B. Each network buffer 124A, 124B has an available space measure,typically 123, which is an indication of how much information the buffer(124A, 124B) can hold before overflowing. The measure of available space123 in the network buffers 124A, 124B will change over time asinformation is written into the network buffers 124A, 124B by thedispatching process 600 and other processes which may be sharing thenetwork buffers 124A, 124B. The available space measure 123 will alsochange as information within the network buffers 124A, 124B istransmitted to connected computer networks 150, 159. Many factors limitthe amount of information which can be transmitted at any point in time.These factors can include the network speed, the bandwidth of thenetwork, congestion of the network, and availability of the network.Certain network resources, such as satellite 150 time, may be availableon a scheduled basis, and their network parameters (e.g. cost, pricing,speed, bandwidth) may vary depending on a time of day.

Block 110 is a mass storage device. In a preferred embodiment, this massstorage device 110 is a disk drive. In alternative embodiments, thestorage device 110 could be one or more disk drives, magnetic tapedrives, memories, or optical drives (e.g. CD-ROM, DVD). The mass storagedevice 110 contains a file system 112 containing zero or more files 112Aand a database 113 which contains zero or more delivery criteria lists114. The file system 112 and database 113 hold the information which thecomputer network dispatching process 600 writes onto the computernetworks 150, 159 through the network buffers (124A, 124B). The massstorage device 110 is connected 116 to the dispatch server 120. In apreferred embodiment, this connection 116 is made via a Small ComputerSystem Interface (SCSI) connection. In alternative embodiments, theconnection 116 could be a network connection or any other connectionused for transmitting data. The connection 116 serves as an input to thedispatch server 120 for accessing the files 112A and databases 113 ofthe mass storage device 110. Connections 116 may also exist between themass storage device 110 and the optional schedule server 130 and requestserver 140.

Block 130 is an optional scheduling server. This server 130 runs ascheduler process 134, an acceptance process 139, a delivery statusprocess 137, and, optionally, a billing process 136 and analysis process138. The scheduler process 134 (and the optional scheduler process 128of the dispatch server 120) schedules one or more portions of the files112A in the mass storage 110 file system 112 for transmission by thedispatch server 120 via its network buffers 124A, 124B. The schedulerprocess 134 (128) does this by writing a transmission decision list 200and a file list 300 in the memory 126 of the dispatch server 120. Thefile list 300 associates files 112A in the file system 112 with thenetwork buffer 124A. The transmission decision list 200 providestransmission criteria 250 (e.g. pacing, timing, and portioninginformation) about the transmission of the files 112A.

The optional billing processes (129, 136) of the dispatch server 120 andthe scheduling server 130 monitor the progress of the dispatchingprocess 600 (600A, 600B) and examine statistics stored in thedispatching process 600 history log 400 and network use criteria table500 in order to determine a cost of a file transmission. Optionally, ananalysis process 138 also examines these statistics (400, 500) to testfor conformance of the dispatching processes 600 to the schedule definedby the scheduler process 134 and for overall system monitoring andactivity charting. In a preferred embodiment, the outputs of the billingprocess 136 and analysis process 138 are stored in a database 113.

The scheduling server 130 contains a memory 131 which contains zero ormore transmission requests 700. The transmission requests 700 containscheduling constraints and information regarding the transmission ofinformation files 112A. Transmission requests 700 are discussed in FIG.7, below.

The acceptance process 139 is a process which determines if it ispossible to schedule a transmission of a file 112A in accordance withthe information in a transmission request 700, taking into considerationnetwork use availability, as recorded in the network use criteria table500, and other pending transmission requests 700. The acceptance process139 is described in FIG. 14, below.

The delivery status process 137 is a process which takes an action (suchas notifying a system operator, or a client 160, 170, 180) when thesystem 100 determines that it cannot meet the scheduling constraints ofan accepted transmission. The delivery status process 137 is describedin FIG. 8, below.

Block 140 is a request server which contains a request receiver process144 and a content generator process 146. The request receiver process144 and content generator process 146 are interfaces by which a requestclient 180 can request the insertion of files 112A into the file system112, request the transmission of files 112A, view the history logs 400and network use statistics 500 generated by the dispatch server 120, andview the outputs of the billing process 136 and analysis process 138. Ina preferred embodiment, the request receiver process 144 and contentgenerator process 146 are web servers and receive/transmit informationfrom/to a request client 180 via the well known Hypertext TransferProtocol (HTTP) protocol. In an alternate embodiment, the requestreceiver process 144 interacts with a request client 180 via the SimpleNetwork Management Protocol (SNMP) protocol and the content generatorprocess 146 interacts with a request client 180 via the File TransferProtocol (FTP) protocol. The request receiver process 144 and contentgenerator process 146 may alternatively interact with a request client180 via a non-real time protocol such as e-mail or message queues. Block142 of the request server 140 is a network connection. The networkconnection 142 provides a connection to a network 159 which is alsoaccessible in real time or non-real time to the client 180 and,optionally, clients 160, 170.

The request server 140 also contains a transmit time process 147 whichdetermines the time requested to transmit a file 112A based on its size,the network speed, the time of day, the size of the network buffers(124A, 124B), and information in the transmission request 700 associatedwith the file 112A. This process 147 is described in the network useallocation process 1200, FIG. 12 below, specifically in step 1235.

Note that servers 120, 130, and 140 can be combined or distributed overone or more computers. Scheduling processes 128 and 134 may also becombined or distributed over one or more computers. Billing processes(129, 136), analysis processes 138, acceptance processes 139, deliverystatus process 137, request receiver processes 144, transmit timeprocesses 147, and/or content generator processes 146 may also becombined or distributed.

Blocks 150 and 159 are two types of computer networks. Block 159 is aninternet/intranet network. Internet/intranet networks 159 are well knownand consists of one or more interconnected switches 153, bridges 154,routers 155, and proxies 156. The intranet/internet network 159 passesdigital messages and transmissions between servers (e.g. 120, 140) andconnected clients (e.g. 170, 180). Each connected server (120, 140) andclient (170, 180) has a network connection (122B, 142, 172, 182,respectively) to the network 159. Line 157 represents the network linksbetween the network connection (122B, 142, 172, 182) and theinternet/intranet network 159. These network links 159 are typicallytelephone lines, cable networks, or wireless networks.

Blocks 150, 151, 152 and 158 form a broadband satellite network. Digitaldata is carried over a network link 158 to a satellite transmitter 151where it is modulated into radio-frequencies (RF) and broadcast into thesky to be reflected/rebroadcast by an orbiting satellite 150. Thereflected/rebroadcast RF encoded data is received at satellite receivers152, demodulated into digital data, and transmitted over a network link158 to a satellite client 160. Blocks 122A and 162 are networkconnections which connect their respective hosts (dispatch server 120and satellite client 160) with the network links 158 of the broadcastsatellite network 150. As a non-limiting example of a network connection162, see U.S. Pat. No. 6,021,419 to Clarke et al. issued on Feb. 1,2000. This Patent is herein incorporated by reference in its entirety.

Blocks 160 and 170 are satellite clients and internet clients,respectively. These clients (160, 170) receive information transmittedthrough the network buffers 124A, 124B of the dispatch server 120 andonto the respective connected computer networks (150, 159) by thedispatching process 600. Each client (160, 170)has a network buffer(164, 174) which buffers information received from the connectedcomputer network (150, 159) and a receiving process (166, 175) whichperforms an action on the received information.

The satellite client 160 is connected to the satellite network 150 vianetwork connection 162. It receives information transmitted by thedispatch server 120 through network buffer 124A. Through well knowprotocols, after the dispatching process 600 writes information into thenetwork buffer 124A, that information will be digitally sent tosatellite transmitter 151 and modulated into RF. The RF encodedinformation will be reflected/rebroadcast by satellite 150 and receivedby satellite receiver 152 to arrive in digital form at networkconnection 162. The information will then enter the network buffer 164of the satellite client 160. The receiving process 166 will be alertedto the presence of the received information in the network buffer 164and will take an appropriate action.

Similarly, internet/intranet client 170 is connected tointernet/intranet 159 via network connection 172. It receivesinformation transmitted by the dispatch server 120 through networkbuffer 124B. Through well known protocols, after the dispatching process600 writes information into the network buffer 124B, that informationwill flow through the internet/intranet network 159 to arrive at networkconnection 172. The information will then enter the network buffer 174of the internet/intranet client 170. The receiving process 175 will bealerted to the presence of the received information in the networkbuffer 174 and will take an appropriate action. The actions of theinternet/intranet client 170 receiving process 175 and the satelliteclient 160 receiving process 166 could include: decoding the informationinto an audio wave form and playing it over a speaker 176; decoding theinformation into a video presentation and displaying it on a monitor177; displaying the information as a web page on a monitor 177; and/orstoring the information on a mass storage device 178.

Block 180 is a requesting client which has a network connection 182 tointernet/intranet network 159. Client 180 has a request process 186which communicates to the request receiver process 144 through networkbuffer 184 and connected network 159. This process 186 createstransmission requests 700 which are sent to the request receiver process144 to schedule transmissions of a file 112A. The client 180 may containan optional mass storage 188 which holds files 112A which are accessedby the content generator process 146 for storage and transfer to thefile system 112 of mass storage 110.

FIG. 2 is a block diagram of the transmission decision list 200 datastructure. The transmission decision list 200 is a sequence of zero ormore transmission criteria 250 that instruct the dispatching process 600(600A, 600B) about how, when, and at what burst rate, a file 112A shouldbe transmitted over a network (150, 159). The transmission criteria 250data structure contains the following fields: an index 205, a releasetime 210, a portion quantity 215, a duration 220, a burst size 225, aburst rate 230, a quantity completion measure 235, and a status code240. The index field 205 contains a reference into the file list 300described in FIG. 3 below. Each value in a transmission criteria 250index field 205 should refer to exactly one file list record 350. In apreferred embodiment, the index field 205 contains a numeric integervalue. In alternate embodiments, the index field 205 can contain anumeric identifier, an alphanumeric identifier such as a filename, or amemory address. Note that multiple transmission criteria 250 may haveindex fields 205 which refer to the same file list record 350.

The portion quantity 215 field defines the quantity of the portion ofthe indexed 205 file 112A, that the dispatching process 600 shouldtransmit. In a preferred embodiment, the portion quantity 215 fieldholds a byte count (e.g. 64000 bytes). In alternative embodiments, theportion quantity 215 field could hold a percentage (e.g. 10%). Therelease time 210 field indicates the minimum time at which therespective portion of the indexed 205 file 112A should be written to thenetwork buffer (124A, 124B) by the dispatching process 600. The duration220 field establishes an end time beyond which no more of the portion iswritten to the network buffer (124A, 124B) by the dispatching process600. In a preferred embodiment, both the release time 210 field and theduration 220 fields hold time stamp values. In an alternate embodiment,the duration 220 field could hold a number which indicated an offset(perhaps in seconds) against the release time 210. Hence, these threefields 210, 215, 220 of the transmission criteria 250 data structuredefine the size of a portion and an interval during which thedispatching process 600 should transmit the respective portion.

Note that in a preferred embodiment, the portion quantity 215 isincluded in the transmission criteria 250 but a value indicating whereportion begins in the file 112A is not specified. As described below,the dispatching process 600 reads each portion from the files 112Astarting with the value located in the cursor 315 field of the file list300. As information within the portion is transmitted, the cursor 315field is increased accordingly. The dispatching process 600 does this sothat as portions of a file 112A are transmitted over a network buffer,e.g. 124A, the information transmitted will be contiguous within thefile 112A. That is, there will be no gaps from one portion to anotherif, due to excessive load on a network, e.g. 150, the dispatchingprocess 600 is unable to write an entire portion quantity 215 amount ofinformation into the network buffer during the time interval specifiedby the release time 210 and duration 220.

The burst size 225 and burst rate 230 fields of the transmissioncriteria 250 data structure are used to specify limits on the amount ofa portion written into a network buffer (124A, 124B) at any specifictime. Together, the burst size 225 and burst rate 230 fields providepacing information to the dispatching process 600. The dispatchingprocess 600 will partition the respective portion of the file 112A intoquantities of a size no greater than the burst size 225 and eachquantity will be written to its respective network buffer (124A, 124B)at a time interval not less than the burst rate 230. This pacinginformation can be used to lessen the chance of information loss throughthe network (150, 159) when, for example, the network buffer (124A,1224B) of the dispatching server 120 is of a different size than thenetwork buffer (164, 174) of a connected client (160, 170). Or when thereceiving process (166, 175) and/or the network buffers (164, 174) of aclient cannot receive an entire portion quantity 215 of information inone transmission. The burst size 225 and burst rate 230 fields areoptional.

The index 205, release time 210, portion quantity 215, duration 220,burst size 225, and burst rate 230 fields of the transmission criteria250 data structure provide input data to the dispatching process 600.

The quantity completion measure 235 and status code 240 fields of thetransmission criteria 250 data structure are filled in, over time, withan output of the dispatching process 600. As the dispatching process 600writes portions, or quantities of partitioned portions, into a networkbuffer (124A, 124B) for transmission, the dispatching process 600 aquantity completion measure 235 will be accumulated. In a preferredembodiment, the quantity completion measure 235 field holds a byte countof information within the partition transmitted. When the value in thequantity completion measure 235 field is equal to the value in theportion quantity 215 field, the portion has been completely written intothe network buffer (124A, 124B). The quantity completion measure 235 andstatus code 240 fields are optional.

The status code 240 field of the transmission criteria 250 datastructure can take on one of the following values: “Pending”, “Active”,“Complete”, and “Timed out”. This field 240 indicates state of thepartition in the transmission criteria 250 data structure. If the statuscode 240 field has a “Pending” or “Active” value, the partitionspecified by the transmission criteria 250 is available to be writteninto the network buffer 124A, 124B by the dispatching process 600(within the time interval specified by the release time 210 and duration220 fields). A “Complete” value in the status code indicates that thedispatching process 600 has completed the writing of the partition intothe network buffer 124A, 124B. And a “Timed out” status code 250 valueindicates that the dispatching process 600 was unable to write theentire portion quantity to the network buffer 124A, 124B before theduration 220 elapsed. The status code 240 field has an initial value of“Pending”. In alternative embodiments, the status code 240 field mayalso take on additional, and more specific, values such as codesindicating mass storage media errors (i.e. parity errors, disk errors),network errors, destination not found errors, and destination notresponding errors.

FIG. 3 is a block diagram of the file list 300 data structure. The filelist 300 is a sequence of zero or more file list records 350 thatcorrelate one or more transmission criteria 250 with individual files112A within the file system 112 of the mass storage 110. The file listrecord 350 data structure contains the following fields: an index 305, asource file identifier 310, an (optional) cursor 315, a destinationaddress 320, and a transmission type 325. The file list records 350identify files 112A in the mass storage 110 that are to be transmittedover one or more of the computer networks (150, 159) connected to arespective network buffer (124A, 124B). The file list records 350 alsoserve to associate the files 112A with the portioning informationdefined in the transmission criteria 250.

The index 305 field holds a value which uniquely distinguishes a filelist record 350 from other file list records 350 in a file list 300. Ina preferred embodiment, the index 305 field holds an integer value. Inalternate embodiments, the index 305 field can hold some other type ofunique value such as a file name or other mass storage identifier andmay also share the same value as the source file identifier 310 field.Or, the index 305 field may be the address in the memory 126 of thedispatching server 120 where the file list record 350 is located. Theindex 305 field is used as a cross reference to the index 205 field intransmission criteria 250 as described above.

The source file identifier 310 field associates the file list record 350with a file 112A in mass storage 110. In a preferred embodiment, thesource file identifier 310 field contains a handle value through whichthe dispatching process 600 can read information from a file 112A inmass storage 110. In alternative embodiments, the source file identifier310 field could contain a file name (e.g. “C:\Data\Video.MPG”), a TCP/IPsocket identifier, or a memory address of a computer process whichdelivered file information as its output.

Hence, through the index 305 field and the source file identifier 310field, the file list record 350 provides an association betweentransmission criteria 250 and files 112A.

The optional cursor 315 field of the file list record 350 is used whenthe information of a file 112A is available in a random access mode. Thevalues of the cursor 315 field indicate where information should be readfrom, by the dispatching process 600, in the identified 310 file 112A.As information is read and transmitted to network buffers (124A, 124B),by the dispatching process 600, the dispatching process 600 (600A, 600B)will update the value in the cursor 315 field. In a preferredembodiment, the cursor 315 field contains integer values with zero beinga “beginning of file” value. In alternate embodiments, the cursor 315field may contain memory addresses or other values appropriate to thetype of mass storage 110 in use.

When the file 112A can only be read in a serial manner (i.e. is not readin a random access manner), the cursor 315 field is omitted from thefile list record 350 data structure.

The destination address 320 field of the file list record 350 identifiesone or more network buffers (124A, 124B) that the dispatching process600 should write the associated portioned 250 file 112A informationinto. The destination address 320 field may further identify one or morenetwork connected client (160, 170) machines which will receive theportioned 250 file 112A information. In a preferred embodiment, thedestination address 320 field holds an internet multicast address.

The transmission type 325 field identifies the protocol to be used bythe dispatching process to transmit the portioned 250 file 112Ainformation. Transmission types can include the well known unicast,multicast, broadcast, internet protocol (IP), IPX, asynchronous transfermode (ATM), UDP, and TCP/IP protocols.

FIG. 4 is a block diagram of the history log 400 data structure. Thehistory log 400 is a sequence of zero or more history records 450 whichprovide an accumulated amount of one or more of the portions 250 offiles 112A transmitted over one or more of the computer networks 150,159 by the dispatching process 600 in an interval. The history logrecord 450 data structure contains the following fields: an index 405, astart time stamp 410, a status code 415, a completion time stamp 420,and a quantity completion measure 425. The history log 400 is an outputof the dispatching process 600.

The index 405 field of the history record 405 holds a value equal to avalue of an index 305 field in a file list record. The start time stamp410 and completion time stamp 420 fields define a time interval. And,the status code 415 field and quantity completion measure 425 fields areprogress indicators which hold a success value and an accumulated amountof portions transmitted by the dispatching process 600 during thespecified interval (410, 420). In a preferred embodiment, the statuscode 415 field can hold the same values as the status code 240 field inthe transmission criteria 250 data structure. Similarly, the quantitycompletion measure 425 field is of the same data type as the quantitycompletion measure 235 field of the transmission criteria 250 datastructure. In alternative embodiments, the progress indicators (415,425) may hold multiple values, e.g. multiple status codes.

During its execution, the dispatching process 600 progressivelypopulates the history log 400 with history records 450. Study of thegrowing history log 400 of history records 450 can provide analysisprocesses 138 and/or billing processes (129, 136) with statistics aboutthe progress of file 112A portion 250 transmissions and the computernetworks (150, 159). Parts of the cumulative history log 400 may also beoffloaded from the memory 126 of the dispatching server 120 and storedin mass storage 110 for off-line analysis. In a preferred embodiment,the dispatching process 600 populates the history log 400 with a historyrecord 450 each time an amount of portioned 250 information is writteninto a network buffer (124A, 124B). In alternative embodiments, thedispatching process 600 may populate the history log 400 lessfrequently, perhaps on a timed basis (e.g. create cumulative historyrecords 450 each minute or hour of activity).

FIG. 5 is a block diagram of an optional network use criteria table 500.The network use criteria table 500 is a sequence of zero or more networkuse criteria records 550 which specify a maximum value of networkresource that is to be used by the dispatching process 600 (600A, 600B)in a given interval of time. The network use criteria record 550 datastructure contains the following: a time stamp 505 field, a definednetwork use 510 field, an aggregate amount of network use 515 field andan optional network identifier 520 field. The network use criteriarecord 550 data structure may also contain a network use window 525field and a remaining bandwidth 530 field.

The defined network use 510 field is used to constrain the dispatchingprocess 600 to use a limited amount of network resource (e.g. bandwidth)starting at a time specified in the time stamp 505. In a preferredembodiment the defined network use 510 field defines a maximum amount ofthe information stored in the files 112A which should be written to anetwork buffer (124A, 124B) after a specific time 505. As information iswritten into the network buffers (124A, 124B) by the dispatching process600, the dispatching process 600 wilt maintain a count of the networkresources (e.g. bandwidth) used in the aggregate amount of network use515 field.

The network use criteria table 500 is most useful when resources of acomputer network (e.g. 150) resources, such as satellite 150 time, arebe available on a scheduled basis, and network parameters (cost, speed,bandwidth) vary depending on time of day. For example, a satelliteuplink facility may lease satellite network 150 bandwidth at 45 Mbpsbetween 4:00 AM and 5:00 AM and 15 Mbps at all other times of the day.To accommodate these constraints in the system 100, a network usecriteria table 500 containing twenty-four network use criteria records550 could be constructed on a daily basis. The twenty-four network usecriteria records 550 could contain successive time stamp 505 valuesranging from 0:00 (midnight) to 23:00 (11:00 PM). The network usecriteria record 550 which had a time stamp 505 value of 04:00 AM couldhave defined network use 510 value of 45 Mbps×60×60 (i.e. the amount ofbandwidth available in that one hour). The other network use criteriarecords 550 could have a defined network use 510 value of 15 Mbps×60×60.

The aggregate amount of network use 515 values written by thedispatching process 600 may be recorded as a supplement to the historylog 400 and stored in mass storage 110 for analysis purposes.

The optional network use window 525 field is used to indicate the lengthof the interval of time the network use is defined 510 for. In apreferred embodiment, this field 525 does not exist in the network usecriteria record 550 data structure, but a value for this field 525 iscomputed on demand. The network use window 525 is a virtual field. Thevirtual network use window field 525 value being the time intervalbetween the time stamp 505 of the network use criteria record 550 andthe time stamp 505 of the network use criteria record 550 with the nextgreater time stamp 505. In alternate embodiments, the network use window525 field may exist in the network use criteria record 550, e.g. occupymemory. In other alternate embodiments, an end time stamp 505 may beused in place of an interval window 525.

The optional remaining bandwidth 530 field is used to indicate an amountof available bandwidth which is available during the time periodspecified by the network use criteria record 550. In a preferredembodiment, the remaining bandwidth field 530 is a virtual field and itsvalue is computed on demand. The virtual remaining bandwidth field 530has a value equal to the difference between the defined network use 510and the aggregate amount of network use 515 divided by the network usewindow 525.

The network use window 525 and remaining bandwidth 530 fields are usedin the network use allocation process 1200, FIG. 12 below, in order forthe network use allocation process 1200 to tentatively reserve portionsof network use.

The optional network identifier 520 field is used to identify whichcomputer network 150, 159 the network use criteria record providesconstraints against when the dispatching server 120 is connected to twoor more computer networks, each with possibly differing constraints.

The dispatching process 600 (600A, 600B) uses the data structuresdescribed above (200, 300, 400, 500) to transmit portions of one or morefiles 112A over the network (150, 159) on a scheduled basis. And, toprovide feedback to processes (e.g. Scheduler process 128, 134, billingprocess 136, analysis process 138) indicating the progress of each file112A portion transmission over time.

FIG. 6 is a flowchart of a dispatching process 600 (600A, 600B) calledthe Dispatch State Machine with Feedback for Scheduled Transmissions.This process 600 transmits files 112A over a computer network (150, 159)based upon transmission criteria 250 contained in a transmissiondecision list 200. The process begins 605 by selecting the transmissioncriteria 250 entry on the transmission decision list 200 with theearliest release time 210 and a status code 240 which is either“Pending” or “Active”. The dispatching process 600 then examines 610 the(optional) duration field 220 of the selected transmission criteria 250.The value in the duration field 220 is compared against the current timeof the system clock 125. If the duration 220 has passed, step 615 storesa “Timed Out” value in the status code 240 field of transmissioncriteria 250 and execution of the process 600 continues to step 675where a next iteration 605 of the dispatching process 600 (600A, 600B)is begun.

If the duration 220 has not passed, the dispatching process 600continues to step 620 where the process 600 pauses in an idle stateuntil the release time 210 of the transmission criteria 250 has passed.In a preferred embodiment of the process 600, this pause 620 may beinterrupted when a new entry 200 is inserted into the transmissiondecision list 200 which has a release time 210 earlier than thecurrently selected transmission criteria 250 or when an existing entryof the transmission decision list 200 is modified so that its releasetime 210 is earlier than that of the currently selected transmissioncriteria 250. When the process 600 is interrupted in this manner,execution returns to step 605. This idle step 620 allows the dispatchingprocess 600 to (a) support schedules which are non-work conserving, (b)ensure that transmissions will not be initiated prematurely before theirspecified release times 210, and (c) allow the throttling oftransmissions to an arbitrarily specified burst rate 225 and burst size230.

For example, a transmission decision list 200 may contain a transmissioncriteria entry 250 with a release time 210 of 05:00 hours. If, duringthe execution of process 600, this entry 250 is selected at 04:45 hours,the process 600 will idle at step 620 for fifteen minutes. During thisidle period the process 600 will write no data to the network eventhough there are entries in the transmission decision list 200 and thuswill be non-work conserving (a). Execution of the process 600 will notresume until 05:00 hours and therefore the portion defined by thetransmission criteria 250 with a release time of 05:00 hours will not betransmitted prematurely (b).

Similarly, suppose that a transmission criteria 250 contains a burstsize field 225 of 10 Kbytes and a burst rate field 230 of 00:01 hours(one minute). After a first amount of data is written by process 600,the transmission criteria 250 will be rescheduled, step 670, with arelease time 210 one minute greater than the first release time. Thiswill cause step 620 to idle until one minute has elapsed and limit theburst rate of the transmission (c).

When the release time 210 of the selected transmission criteria 250 hasarrived (or has past), the dispatching process 600 checks foravailability of bandwidth, step 625. A network use criteria record 550is chosen from the network use criteria table 500, and the definednetwork usage 510 is compared against the aggregate amount of networkusage 515 to determine a network resource availability. In a preferredembodiment, the defined network usage 510 field and the aggregate amountof network usage 515 fields hold integer amounts of bandwidth. Equalvalues of the two fields (510, 515) indicate that there is no availablebandwidth, and upon finding equal values, the process moves into asecond idle state 630. The process 600 will idle 630 until the timespecified in the time stamp 505 field of the next entry of the networkuse criteria table 500. After the idle time of step 630 has elapsed,execution resumes to step 685 and then step 605 where a second iterationof the dispatching process 600 is begun.

The network use criteria record 550 is chosen from the network usecriteria table 500 by selecting the record in the network use criteriatable 500 which has the greatest time stamp field 505 that is less thanor equal to the time of the system clock 125. By using the system clock125 as an index into the network use criteria table 500, the dispatchingprocess 600 can operate on and take advantage of computer networks, e.g.150, where the network resources available varies over time.

Refer now to FIG. 6A which is a flow chart of an amount-to-writecomputation process 635A.

The dispatching process 600 continues 635 by computing an amount of data635 to write.

This amount 635 will be used by the process 600 during the reservationand write steps (640, 645 respectively) described below when the process600 writes information into a network buffer 124A, 124B. In a preferredembodiment, the amount 635 is the minimum (e.g. byte length) 636 of thefollowing values: (a) the quantity of network resources currentlyavailable 510 less the aggregate amount of network use 515 in thenetwork use criteria table 500; (b) the portion quantity 215 valuestored in the currently selected transmission decision list entry 200;(c) the burst size 225 value also from the currently selectedtransmission decision list entry 200. Each of these fields (515, 215,225) can have optional “not-specified” values which indicate that nonumber is given in the respective field. Fields which contain thenot-specified value are ignored for purposes of calculating the amountof data 635 to write. In alternate embodiments, these fields (515, 215,225) are optional and may be ignored during the calculation 635. Anembodiment may also include (d) the available space 123 in a networkbuffer (124A, 124B) as a further factor in the minimum calculation.

The portion quantity 215 value of the transmission criteria 250 ischosen as a candidate for the amount of data to write 635 because itindicates the maximum total amount of data which should be transmittedfor the transmission decision list entry 200. This value may be smallerthan the burst size 225 and the network resources available 510, 515. Ifthe process 600 were to write more than quantity to write 215 bytes, theprocess could read past a buffer, encounter an end-of-file error, orwrite more data than the transmission criteria 250 called for.

The burst size 225 value of the transmission criteria 250 is chosen as acandidate for the amount of data to write 635 because it indicates theamount of data which should be transmitted for the transmission criteria250 during a burst rate 230 interval. The process 600 will not writemore than burst size 225 bytes for any transmission during a burst rate230 interval. The process 600 paces itself in this manner so as not tooverwhelm the networks 150, 159 with data and so that network buffers inthe server computer (124A, 124B), network devices at intermediate points(e.g. proxies 156, routers 155, switches 153, bridges 154), andreceiving buffers (164, 174) and receiving processes (166, 175) inclient computers (160, 170) will be able to handle the network load.

Now refer back to FIG. 6.

After computing the amount to write 635 value, the dispatching process600 then 640 reserves bandwidth from the network use criteria table 500.In a preferred embodiment this reservation is done by increasing theaggregate amount of network use 515 field of the network use criteriarecord 550 selected in step 625 by the amount to write value 635. Inalternate embodiments the reservation may be performed using a secondtable or other data structure. This reservation prevents two or moreinstances of this process 600 which may be running concurrently fromwriting more data to a network (150, 159) than it can handle.

The dispatching process 600 then proceeds 645 to write data into anetwork buffer (124A, 124B). The process 600 does this by locating thefile list record 350 in the file list table which has a file list index305 that is equal to the index 205 in the selected transmission criteria250. Data is then read from the file 112A referenced by the source fileidentifier 310 starting at the location specified by the cursor 315. Theread data is written to the network buffer (124A, 124B) identified bythe destination address 320, optionally, accompanied with thedestination reference 320. The amount to write value computed in step635 is used to place a limit on how much data is written at this step645. In a preferred embodiment, the data is written in a non-blockingmanner so that execution of the dispatching process 600 will not bedelayed by a block waiting for a network buffer 124A, 124B to clear. Thedispatching process 600 also maintains a timer and monitors the elapsedtime of the write operation 645. If the time of the system clock 125passes the duration 220 specified in the transmission criteria 250 orthe elapsed time exceeds the burst rate 230, the process cleanlypreempts (rather than aborting) its write operation 650. In alternateembodiments, the process 600 may also conditionally interrupt the writeoperation 650 when the transmission criteria 250 is modified by a secondprocess (i.e. a scheduler).

When its write operation 645 completes (normally or preemptively), thedispatching process 600 updates fields 655 within the transmissioncriteria 250, the file list record 300, and the network use criteriarecord 550 to reflect the transmission (writing of data step 645).Within the selected transmission criteria 250, the portion quantityfield 215 is decremented by the amount of data written (which may beless than the value computed in step 625 if the write operation wasinterrupted), and the quantity written field 235 is incremented by thesame amount. The cursor 315 field in the selected file list record 350is incremented by the amount of data written. And within the selectednetwork use criteria record 550, the aggregate amount of network use 515is decremented by the difference between the amount of resources usedand the amount of network resources estimated by the amount of data towrite 625 (in order to give back any unused resources previouslyreserved in step 640).

The dispatching process 600 then 660 edits the history log 400 to recordthe transmission 645 event. Step 650 appends a new history record 450 isappended to the history log 400. The index field 205 value of theselected transmission criteria 250 is copied into the history record 450index 405, the time reading from the system clock 125 in step 625 iscopied into the start time stamp field 410, the time reading from thecurrent system clock 125 is copied into the completion time stamp field420, and the amount of data written in step 635 is recorded into thequantity completion field 425. Further, a status code (e.g. “Success”,“Preempted due to duration”, “Preempted due to transmission criteriamodification”, “Preempted due to network error”, “Preempted due to diskerror”, “File not found”, . . . ) is written into the status code field415.

These two steps (655, 660) allow other processes (e.g. Schedulers 128,134, billing 129, 136, analysis processes 138, and feedback processes1300, described in FIG. 13 below) to monitor the progress of filetransmissions. By updating the history log 400, the dispatching process600 can provide feedback to a scheduler (128, 134) so that it candynamically reschedule transmissions due to delays in the network or dueto unexpected increases in network bandwidth. Analysis processes 138 mayalso use this information to check the network and state machine forconformance to and variances from a defined schedule. These otherprocesses may also monitor changes made by the dispatching process 600to the transmission criteria 250 and file list records 350.

The dispatching process 600 then, step 665, examines the portionquantity 215 field of the transmission criteria 250. If the portionquantity 215 field has a value of zero, step 680 marks the status codefield 240 of the transmission criteria 250 as “Complete” and thedispatching process 600 will no longer select the transmission criteria250 during step 605. Execution of the process 600 continues to step 685and to step 605 where a next iteration of the process begins.

If the portion quantity 215 field of the transmission criteria 250contains a non-zero value, step 610 marks the status code 240 field“Active” and transmission criteria 250 remains a candidate for selectionin step 605. If an optional burst rate 230 was specified in thetransmission decision list entry 200, the release time 210 field isincremented by the burst rate 230 in step 675. This will cause thedispatching process 600 to not transmit any more data for thistransmission criteria 250 until the duration of time specified in theburst rate 230 has passed 620. Execution of the process 600 continues tostep 685 which is simply a jump to the start of the process 600, step605, where a next iteration of the process 600 will commence.

The present invention is now described in more detail in FIGS. 7 through14.

FIG. 7 is a block diagram of a transmission request 700. Transmissionrequests 700 are received from a client 180 by the request receiverprocess 144, described in FIG. 1 above. In a preferred embodiment, amessage containing a transmission request 700 is sent from the client180 to the request receiver process 144 via HTTP (the HypertextTransport Protocol). The transmission request 700 data structurecontains information which instructs the schedule architecture 800 toretrieve, transmit over a network (150, 159), and optionally confirmtransmission of a data file 112A. The transmission request 700 containsfields that specify retrieval, packaging, billing, transmission, and/oracknowledgment requirements of the transmission. For example, thesefields may specify: (a) how the data file 112A should be retrieved froma client 180 machine; (b) how the system 100 can bill the client 180 forwork performed; (c) when the transmission should take place, and whichdestination clients (160, 170) should receive the transmission; and/or(d) what acknowledgments the client 180 wants regarding the successand/or failure of the transmission.

The fields (a) which specify how the data file 112A should be retrievedfrom a client 180 machine may include: a source address 710, a retrievaloptions field 712, a retrieval start time 714, a retrieval intervalfield 716, a maximum retrieval count field 718, a packaging optionsfield 720, and/or an expected data file size 722 field.

The fields (b) which specify how the system 100 can bill the client 180for the work performed may include: a billing account field 730, anoptional billing user field 732, and/or an optional billing cost field734.

The fields (c) which specify when the transmission should take place,and who should receive the transmission may include: a transmissionpriority field 740, a transmission release time field 742, atransmission deadline field 744, a retransmission interval field 746, aretransmission count field 748, a list of recipients 750, and/or abandwidth constraints field 752.

The field (d) which specifies what acknowledgments the client 180 wantsregarding the success and/or failure of the transmission is theacknowledgments field 760.

In a preferred embodiment of the system 100, the data file 112A which isto be transmitted over the network (150, 159) is not included in thetransmission request 700. Instead, the transmission request 700 containsinformation which instructs the content generator process 146, describedin FIG. 1, how and when to retrieve the data file 112A. The sourceaddress field 710 contains an address, e.g. a Uniform Resource Locator(URL), which indicates where the data file 112A can be retrieved from.An optional retrieval options field 712 contains additional informationsuch as a userid and password which is used in conjunction with thesource address 710 to retrieve the data file 112A over the network. Apreferred embodiment of the system 100 includes scheduling information(714, 716, 718) which indicates when the data file 112A should beretrieved. The retrieval start time field 714 indicates a time when aretrieval of the data file 112A should be attempted. The retrievalinterval field 716 indicates an interval, typically in seconds, afterwhich a next retrieval should be attempted should a retrieval fail. Themaximum retrieval count 718 field indicates the maximum number ofretrieval attempts which should be made by the content generator process146. An expected data file size 722 field is also included in thetransmission request 700 and contains a well known quantization of thesize of the file 112A to be transmitted. Typically, the field 722contains a count of bytes.

There are many different ways to bring a data file 112A from a client180 to the mass storage 110. Alternative embodiments of the system 100may not include retrieval scheduling information (fields 714, 716, and718) in the transmission request 700 and may perform one and only oneretrieval attempt at the time the transmission request 700 is received.Other embodiments perform a fixed number of attempts. Further, the datafile 112A may not be available over a connected network (150, 159) fromthe client 180 and need to be physically brought into the system 100.The data file 112A may arrive at a location accessible to the contentgenerator process 146 on a CD-ROM, DVD disc, or VHS cassette tape. Inthese cases, alternative fields which include case-specific schedulinginformation (e.g. media type and a shippers tracking number) may beincluded in the transmission request 700.

After a data file 112A is stored in mass storage 110, optional packagingtransformations may be performed on the data file 112A prior to itstransmission. These transformations could include encryption,compression, or generation of forward error correction codes. The(optional) packaging options field 720 is used to indicate which, ifany, transformations should be applied to the data file 112A.

In alternative embodiments, an additional field, the information contentfield 765, is included in the transmission request 700, in place of thefields pertaining to the retrieval of the data file 112A (710, 712, 714,716, 718). In this embodiment, the expected data file size 722 field maybe omitted and the size of the data stored in the information contentfield 765 used in its place.

The client 180 indicates how the transmission should be charged throughthe billing account 730 and billing user 732 fields of the transmissionrequest 700. The billing account 730 field holds an accountnumber/identifier such as a MasterCard or VISA credit card number or apreviously negotiated identifier. The (optional) billing user 732 fieldcontains a name or other identifier of the person placing thetransmission request 700.

The (optional) billing cost 734 field specifies a maximum cost that canbe charged to the billing account 730 for the requested transmission. Ina preferred embodiment, the billing cost 734 field is omitted and thecost of a transmission depends on other fields in the transmissionrequest (expected data file size 722, retransmission count 748,transmission release date 750, transmission deadline 744, and selectedacknowledgments 1356). In alternative embodiments, the billing cost 734field is used and can hold a dollar amount.

Several of the fields in the transmission request 700 hold details aboutwhen the transmission should take place, and who should receive thetransmission. An optional transmission priority 740 field holds akeyword indicating a selected priority of the transmission. Thesekeywords can include values such as “two day delivery”, “acknowledgedovernight delivery”, and “freight”. These values are used within theschedule architecture 800, particularly in the acceptance process 139,and the schedule process (128, 134) to indicate a desired quality andspeed of service. A “two day delivery” keyword would indicate that afile 112A should be transmitted within 48 hours of receipt of thetransmission request 700. A “acknowledged overnight delivery” keywordwould indicate that a file 112A be transmitted before the next morningand that acknowledgments be returned by each recipient of the file 112A.A “freight” keyword would indicate that the file 112A be transmittedwithin a week of receipt of the transmission request 700.

In a preferred embodiment, the transmission priority 740 field isomitted from the transmission request 700. Instead of specifying apriority 740, the transmission request 700 contains additional fields.The optional transmission release time 742 is the time after which thecustomer wants the file transmitted. The transmission deadline 744 isthe time before which the file 112A must to be transmitted. Note thatthese times can also be specified by a release time 744 and atransmission send window time, or a transmission deadline 744 and atransmission send window time.

The optional recipients 750 field designates the locations/people thatare to be sent the file 112A. Recipient information 750 is typicallyused when retransmissions 748 and/or acknowledgments 760 are used. In abroadcast situation, the recipients 750 need not be specified becauseeveryone on the network will be sent the file.

The optional acknowledgments field 760 is used to indicate when anacknowledgment is required from one or more of the recipients. One typeof acknowledgment 760 indicates that a recipient received the file 112A,or parts of the file 112A. Another type of acknowledgment, a negativeacknowledgment, indicates that the recipient did not receive the file112A or did not receive parts of the file. For example, if a recipientexpected a file 112A at 10:00 PM and did not receive it, it would send anegative acknowledgment. If a recipient received a portion of a file112A and another portion of the file 112A was not received (e.g. due tobeing timed out 615, or due to network 150, 159 error), the recipientwould send an acknowledgment indicating partial reception. In someembodiments of the system, this would cause a retransmission 748 to takeplace.

The optional bandwidth constraints field 752 defines the bandwidthrequirements for a particular file 112A transmission. The bandwidthrequirements can depend on the capabilities of the recipients, thequality of service that a subscriber paid for, and/or the physicalrequirements of the file 112A (e.g. constant bitrate video requires aminimum bandwidth for real-time playback).

The optional retransmission fields (746, 748) indicate that the client180 requests retransmission of the file 112A if no acknowledgment ornegative acknowledgment is received by any of the recipients.Retransmissions (746, 748) must conform to deadline 744 and bandwidth(625, 752) availability requirements. The optional retransmissioninterval field 746 indicates an interval, typically in seconds, afterwhich a next transmission (i.e. a retransmission) should be attempted.The retransmission count 748 field indicates the maximum number ofretransmissions which should be performed.

The collection of fields 740, 742, 744, 746, 748, 752, and 722 is knownas a transmission constraint 770.

FIG. 7A shows an example transmission request 700A. In this non limitingexample, a subscriber such as a product or service provider, e.g. aninsurance company providing digitized training videos, located at thesource address 710, to its representatives (recipients 750), requeststhat the videos 710 be sent out over a weekend in order to be used in acourse in the following week (transmission deadline 744). The company(billing account 730) requests a quality of service which provides tenmegabits of bandwidth (bandwidth constraint 752), collection ofacknowledgments 760 from the representatives, and a maximum of tworetransmissions (retransmission count 748). The video is 3.6 Gigabyteslong (expected data file size 722), approximately two hours of MPEG-2compressed audio and video, and there are two groups of recipients:group B, the insurance agents, and group D, state regulators (see valuesin recipients field 750).

If this transmission request 700A is accepted into the system 100, thevideo file 112A will be retrieved from the source, e.g. FTP site, givenin the source address 710. A maximum of three retrieval attempts(maximum retrieval count field 718) will be made. The first retrievalattempt will begin at or after 21:00 on Thursday (retrieval start time714). Should the first retrieval attempt fail, a second retrieval willbe attempted at or after 03:00 Friday, and possibly a third retrievalattempt at or after 09:00 Friday, per the six hour retrieval interval716. The source address 710 is public and no userid and password isspecified in the retrieval options field 712, which is empty. Once it isretrieved, the file 710 will be stored locally, in mass storage 110, asa data file 112A. The transmission request 700 a indicates that noadditional transformations (encryption, compression) should be performedafter the data file 112A retrieved (see packaging options field 720).

In this transmission request 700A, the transmission priority field 740is empty and therefore the other transmission related fields (742, 744,746, 748) specify details about the scheduling of the file 112A networktransmission and retransmissions. The transmission release time 742indicates that the retrieved file 112A should be transmitted no earlierthan 21:00 on Friday night and that all transmissions andretransmissions should conclude on or before 23:00 Friday (transmissiondeadline 744). The transmissions should be broadcast at approximately 10megabits per second (bandwidth constraints 752). And two retransmissions748 are requested after intervals of thirty minutes (retransmissioninterval 746). A transmission of a 3.6 GB file at 10 Mbps will takeeight minutes to complete. In an alternative embodiment, thetransmission priority field 740 can be specified as described above andtheir will be no need to fill in fields 742, 744, 746, 748.

Charges for the retrieval, transmission, retransmissions, andacknowledgments the system 100 performs for this request 700A will bebilled to the Insurance Company (billing account 730). The transmissionrequest 700A does not specify a billing user 732, and does not place anyrestrictions on the amount to be billed 734. Billing user field 732could specify a specific individual at the insurance company that madethe transmission request and/or be used to identify sub-accounts withinthe company, e.g. the education department. Billing cost field 734 isfilled by the user to indicate the maximum amount the user is willing topay for this transmission request 700. If the maximum amount exceeds thecost of the transmission request 700 and the transmission is successful,no action is taken. However, if no retransmission count is specified,retransmissions will continue if no acknowledgment is received until theamount specified in the billing cost 734 is exhausted.

FIG. 8 is a block diagram of the architecture 800 of the scheduler (128,134) with an optional estimate transmissions process 1000 and otherrelated functions. The architecture 800 is a system and method forscheduling digital information transmission and retransmission on anetwork during time slots.

Transmission requests 700 arc received from a client 180 by the requestreceiver process 144, described in FIG. 1 above. The transmissionrequest 700 contains transmission constraints 770 such as transmissiontiming information as explained in the description of FIG. 7 (and inexample in FIG. 7A) and, in a preferred embodiment, pricing information.In some embodiments, the request receiver process 144 would notify theclient 180 whether or not the transmission request 700 was accepted bythe system 100. For example, a notice would be sent to the client 180 ifthe billing cost amount 734 was too low for the service requested or ifthe network could not accommodate the transmission constraints (740,742, 744, 746, 748, 752, 722), typically 770.

The received transmission request 700 is passed to an acceptance process139, described in FIG. 14 below. The acceptance process 139 determinesif it is possible to schedule a transmission of the information in thetransmission request 700 in accordance to the received transmissionconstraints 770. In an alternative embodiment, the acceptance process139 is not used and a delivery status function 137 provides theacceptance function.

If the transmission request 700 for transmission is rejected by tileacceptance process 139, the request receiver process 144 is notified(and optionally notifies the client 180) and a next request 700 isreceived. In a more preferred embodiment, the request receiver process144 includes alternate transmission constraints 770 categorized bypriority so that the acceptance process 139 can reject the transmissionrequest 700 with one or more of the constraints 770 but accept thetransmission request 700 with one of the other constraints 770. In analternative preferred embodiment, the acceptance process 139 wouldreject the transmission request 700 but would return through the requestreceiver process 144 to the client 180 alternate criteria (e.g.transmission time availability and pricing) which is used in anegotiating process between the system 100 and the client 180 to come toan acceptable transmission constraints 770 for the transmission request700. In another embodiment, the client 180 submits multiple transmissionrequests 700 with different transmission constraints 770, probablystarting with the most constrained transmission request 700 first. Theclient 180 continues submitting transmission requests 700 until thesystem 100 accepts one.

If a transmission request 700 is accepted, it is passed to a contentgenerator process 146 as described in FIG. 1 above. The contentgenerator 146 has two functions: a schedule retrieval function 841; anda retrieval function 843. The schedule retrieval function 841 determinesif the file 112A to be transmitted to satisfy the transmission request700 is available, e.g. in the system mass storage 110. If the file 112Ais available, the file is associated with the accepted transmissionrequest 700 that contains the transmission constraints 770 for the file112A. If the file 112A is unavailable, the schedule retrieval function841 requests the retrieval function 843 to take an action to access theassociated file 112A. Such actions might include: notifying an operatorto load a disk, tape, or CD; sending a request over the network, e.g. tothe client 180 to transmit the file 112A. The access of the file 112Athat is not available in the system memory 110 may occur hours or daysafter the request receiver process 144 receives the transmission request700. Preferably, the file 112A will be brought into the massstorage/system memory 110 before the time specified in the transmissionrelease time 742. If the file 112A is accessed late, corrective actionwill be taken by the feedback process 1300 as described in FIG. 13below. Note that the files 112A may be stored in the mass storage 110and at different times be sent by different transmission requests 700.

In a preferred embodiment, the retrieval function 843 access the files112A and ensures that they are in the memory 110. Upon receiving a file112A into memory 110, the retrieval function 843 (a) associates the file112A with the transmission request 700 and (b) stores the actual file112A size in the expected data file size field 722. The association (a)is done because the location of the file 112A in the mass storage/systemmemory 110 may not be known until the file is received into memory 110.The expected data file size field 722 is updated (b) upon receipt of thefile 12A because the exact size of the file 112A may also not be knownuntil the file 112A is received and may be relevant to the pricing ofthe transmission.

The schedule retrieval 841 and retrieval 843 functions may be separateprocesses or performed as part of other processes in the system 800(e.g. the request receiver process 144).

The schedule process (128, 134) contains an estimate transmissionsprocess 1000 which receives an accepted transmission request 700 and itsassociated file 112A. This process 1000, modified by feedback process1300 and an optional acknowledgment receiver process 135, repeatedlycreates and/or modifies delivery criteria records 914 in the deliverycriteria list 114 to schedule the transmission of the file 112A to meetthe transmission constraints 770. The estimate transmission process 1000is described in more detail in FIG. 10, below. The acknowledgmentreceiver process 135 is described in more detail in FIG. 13, below. Thedelivery criteria records 914 of the delivery criteria list 114 aredescribed in more detail in FIG. 9, below.

In a preferred embodiment, entries in the transmission decision list 200and file list 300 described above in the description of FIGS. 2 and 3,are created by the schedule dispatch process 1100 and network useallocation process 1200, see FIG. 11 and 12 below, based on informationin the scheduled delivery criteria list 114. These lists (200, 300) areused by the dispatching process 600 (600A, 600B) to transmit the files112A and to generate the history log 400 and the network use criteriatable 500 as described in FIGS. 4, 5, and 6 above. The history log 400and network use criteria table 500 are used in the feedback process1300.

Hence, this architecture 800 is used in and further defines the system100 where digital information (e.g. Files 112A) are accepted fortransmission (request receiver process 144, acceptance process 139),scheduled (estimate transmissions process 1000, schedule dispatchprocess 1100, network use allocation process 1200), and transmitted(dispatch process 600).

Note that the associated file 112A may or may not be present in thememory 110 at the time process 1000 adds and/or modifies deliverycriteria records 914 in the delivery criteria list 114. Therefore, thesystem 800 allows reserving a transmission time with certain deliverycriteria records 914 without having the actual file 112A to betransmitted. In this way, the file 112A, meeting the transmissionconstraints 770, can be under development up until the time thetransmission request 700 requires transmission. This feature is usefulin transmitting dynamic data, e.g. news or weather data, which isunavailable until just before the transmission time in the transmissionconstraints 770. The feature is also useful in reserving a transmissiontime for data which is being developed in parts and transferred atvarious times and unified at a distant location. In this case, a dailytime is reserved for transmission of files for information to be used,assembled, and examined in a collective work at another location.

For example, an on-line university may transmit a digitized lecturewhich is a portion of a digitized course one or two times a week at acertain time to its students. The availability of each lecture, asmeasured in terms of the time before transmission may vary. And the sizeof each lecture, as measured in terms of the file length of thecompressed and/or digitized data file may vary. Some lectures maycontain large image files, MPEG video, and lecture notes, while otherlectures may just contain voice.

In one preferred embodiment, delivery criteria records 914 for files112A that are unable to be scheduled in conformance with theirassociated transmission constraints 770 are dropped. This could occurdue to dynamic changes in the system 100, e.g. delays, unforeseenincreases in file sizes 722 which are delivered prior to the deliverycriteria record 914, or time-out situations 615, or a transmissionrequest 700 with a higher priority taking precedence of the system 100resources. In a preferred embodiment, when delivery criteria records 914are dropped, the schedule dispatch process 1100 sends a signal to adelivery status module 137.

The delivery status module 137 first receives the dropped signal 882.For delivery criteria records 914 that are dropped, the delivery statusmodule 137 estimates 884 the impact of dropping the delivery criteriarecord 914. This is done by determining to what extent other deliverycriteria records 914 associated with the same file 112A have beensatisfied. For example, if the file 112A of a dropped delivery criteriarecord 914 is scheduled for periodic retransmission and it is expectedthat these future retransmissions would satisfy the transmissionconstraints 770 for all or some of the recipients 750, no action may berequired at this time, but may be required later. However, if this timeis the only time the file 112A is transmitted and the file has a highpriority, a dropped delivery criteria record 914 might have to berescheduled at a later time, and this rescheduling may affect thecurrent dispatch schedule.

Step 886 determines if the impact of dropping a delivery criteria record914 exceeds a threshold. If the impact exceeds a threshold, correctiveaction 888 is taken.

For example, in one preferred embodiment dropping any delivery criteriarecord 914 exceeds the threshold 886 and the action taken 888 would beto alert an operator. In an alternative embodiment, the number ofdelivery criteria records 914 dropped is counted and if the countexceeds a count threshold, a program such as Tivoli is alerted toincrease the network bandwidth allotted to the system 100, when deliverycriteria records 914 are being dropped due to network bandwidthproblems. (Tivoli is a registered trademark of the IBM Corporation). Ina further alternative embodiment, the system 800 determines why adelivery criteria record 914 was dropped and the corrective action 888taken is to reschedule transmission with a new delivery criteria record914 that permits the file 112A to be transmitted.

In another alternate embodiment, the corrective action 888 taken is forthe scheduler (128, 134) to reschedule a transmit time after the digitalinformation (portion of file 112A) is rejected (dropped). The scheduler(128, 134) may also contain a rejection queue and reclamation policy. Inthis alternate embodiment, as transmissions for files 112A are dropped,they are placed on the rejection queue. A rejection policy within theestimate transmissions process 1000, FIG. 10 below, and/or within theSchedule Dispatch process 1100, FIG. 11 below, pulls entries from therejection queue when as network bandwidth becomes available or whenacknowledgments 135 are received and transmission constraints 770 aresatisfied sooner than expected.

In another alternate embodiment, the corrective action 888 taken is toalert the acceptance process 139 of a network bandwidth shortage. Uponreceiving the alert, the acceptance process 139 would refuse (or limit)the acceptance of transmission requests 700 with transmissionconstraints 770 that required transmission during a time window aroundthe network bandwidth shortage time period. For example, in thisalternate embodiment, the acceptance process 139 would refusetransmission requests 700 during days (peak hours, off-peak hours, . . .) where one or more preexisting delivery criteria records 914 weredropped. Or, the acceptance process 139 could refuse transmissionrequest 700 higher than a given priority during time periods of knownnetwork congestion.

An alternative corrective action 888 is described in the acceptanceprocess 139, FIG. 14, below.

FIG. 9 is a block diagram of one preferred storage filing system 110.The storage system comprises any known storage means 110 which containsone or more filing system data structures 112. These filing systems 112contain files 112A to be transmitted by the system 100. The storagesystem 110 also comprises a database 113 which contains a deliverycriteria list 114. The delivery criteria list 114 has a plurality ofrecords, typically 914. Each delivery criteria record 914 has thefollowing fields: a file list record 350 (see description, FIG. 3,above); a file size 922; a release time 924; a deadline 926; one or moreoptional recipients 928; an acknowledgment designator 930; an optionalbandwidth 932; and an optional retransmission designation 934.

In a preferred embodiment, the delivery criteria records 914 of thedelivery criteria list 114 are created and maintained by the estimatetransmissions process 1000, described in FIG. 10, below. The process1000 creates one or more delivery criteria records 914 for eachtransmission request 700 and each record 914 represents a transmissionof the transmission request's associated data file 112A. Deliverycriteria records 914 may also represent a retransmission of some or allportions of an associated data file 112A.

Each delivery criteria record 914 contains (or references) a file listrecord 350. This file list record field 350 identifies the file 112Awhich is to be transmitted to satisfy the delivery criteria record 914.

The file size field 922 is any well known quantization of the size ofthe file (350, 112A) to be transmitted. Typically the file size 922 isgiven in byte lengths. The release time field 924 is the time afterwhich the file (350, 112A) should be transmitted. The deadline field 926is the time before which a transmission of the file (350, 112A) shouldcomplete. Note that these times can also be specified by a release time924 and a send window time, or a deadline 926 and a send window time.

The optional recipients 928 designate the location/people that are to besent the file (350, 112A). Recipient information 928 is typically usedwith retransmissions 934 and/or acknowledgments 930 are used. In abroadcast situation, the recipients need not be specified becauseeveryone on the network will be sent the file (350, 112A).

The optional acknowledgment field 930 is used to indicate when anacknowledgment is required from one or more of the recipients. One typeof acknowledgment 930 indicates that a recipient received the file (350,112 a), or parts of the file (350, 112 a). Another type ofacknowledgment, a negative acknowledgment, indicates that the recipientdid not receive the file (350, 112 a) or did not receive parts of thefile. For example, if a recipient expected a file (350, 112 a) at 10:00PM and did not receive it, it would send a negative acknowledgment. If arecipient received a portion of a file (350, 112 a) and another portionof the file (350, 112 a) was not received (e.g. due to being timed out615, or due to network 150, 159 error), the recipient would send anacknowledgment indicating partial reception. In some embodiments of thesystem, this would cause a retransmission 934 to take place.

The optional bandwidth field 932 defines the bandwidth requirements fora particular file (350, 112 a) transmission. The bandwidth requirementscan depend on the capabilities of the recipients, the quality of servicethat a subscriber paid for, and/or the physical requirements of the file(350, 112 a). (Constant bit rate video requires a minimum bandwidth forreal-time playback).

The optional retransmission field 934 indicates that a client 180requires retransmission of the file if no acknowledgment or negativeacknowledgment is received by any of the recipients. Retransmissions 934must conform to deadline (615, 926) and bandwidth (625, 932)availability requirements.

An example of a delivery criteria list 114 is shown in FIG. 9A. This nonlimiting example is a continuation of the example given in FIG. 7A.Referring to FIG. 7A, a subscriber such as a product or serviceprovider, e.g. an insurance company providing digitized training videos,located at the source address 710, to its representatives (recipients750), requests that the videos 710 be sent out over a weekend in orderto be used in a course in the following week (transmission deadline744). The company (billing account 730) requests a quality of servicewhich provides ten megabits of bandwidth (bandwidth constraint 752),collection of acknowledgments 760 from the representatives, and amaximum of two retransmissions (retransmission count 748). The video is3.6 Gigabytes long (expected data file size 722), approximately twohours of MPEG-2 compressed audio and video, and there are two groups ofrecipients: group B, the insurance agents, and group D, state regulators(see values in recipients field 750).

Now referring to FIG. 9A. There are five delivery criteria records 914(A, B, C, D, E) in the example delivery criteria list 114. Deliverycriteria records 914A, 914B, and 914C are criteria for the transmissionand retransmission of the transmission request shown in FIG. 7A.Delivery criteria record 914A requests a transmission of the 3.6 GB(size 922) file 112A “training.mpg” (source file identifier 310 in filelist record 350) to be performed between 21:00 Friday (release time 924)and 23:00 Friday (deadline 926) to the recipient groups B and D(recipients 928) with acknowledgments 930 at a bandwidth of 10 Mbps(bandwidth 932). Delivery criteria record 914A also indicates that tworetransmissions 934 may follow. Delivery criteria records 914B and 914Care identical to delivery criteria record 914A except that they havedifferent release times 924 (21:30 Friday and 23:00 Friday,respectively) and different retransmissions fields 934 (containingvalues of one and zero respectively).

Delivery criteria records 914D and 914E are the criteria records forother transmission requests 700. Delivery criteria record 914D requestsa transmission of the 375 MB (size 922) file 112A “rulesUpdate.zip”(source file identifier 310 in file list record 350) to be performedbetween 21:30 Friday (release time 924) and 22:00 Friday (deadline 926)to the recipient groups A and B (recipients 928) with no acknowledgments930 or retransmissions 934 at a bandwidth of 5 Mbps (bandwidth 932).Delivery criteria record 914E requests a transmission of the 750 MB(size 922) file 112A “catalog.zip” (source file identifier 310 in filelist record 350) to be performed between 22:00 Friday (release time 924)and 22:30 Friday (deadline 926) to recipient group C (recipients 928)with no acknowledgments 930 or retransmissions 934 at a bandwidth of 10Mbps (bandwidth 932).

In this example, delivery criteria 914A, 914B, and 914C request threetransmissions of their associated file 112A. The three transmissions areto be scheduled with release times 924 that are thirty minutes apart.Thirty minutes being the retransmission interval 746 of sampletransmission request 700A.

Note that delivery criteria 914B and 914D have the same release time 924value.

In this example, the system 100 sent the entire package during anavailable network slot on Friday night 924. However, due to a cut cablenetwork outage, the regulators (recipients 928 group D) did not receivethe package and did not send an acknowledgment. Also, because of clientlimitations, the agents (recipients 928 group B) only received half ofthe package. Since the agents only acknowledged receipt of half of thepackage, and no acknowledgment was received from the regulators, theentire package was retransmitted to the regulators and the missing halfwas retransmitted to the agents. These functions were performed by thescheduling process (128, 134). Criteria for different transmissionrequests 700 are given in each of the records (typically 914) of thedelivery criteria list 114 containing the delivery criteria records 914.

FIG. 10 is a flow chart of an estimate transmissions process 1000. Thisprocess 1000 receives accepted transmission requests 700 and createsrecords 914 in the delivery criteria list 114 so that the associatedfiles 112A will be transmitted by the system 100. The schedule process(128, 134) executes the estimate transmissions process 1000 each time anew transmission request 700 is accepted 841 into the system (128, 134),and each time information is generated (e.g. an exact file 112A size isdetermined, a prior transmission of the file 112A completes 1300, andacknowledgments 135 are received from clients 160, 170) regarding thetransmission request 700. When executed, the estimate transmissionsprocess 1000 will modify the delivery criteria list 114 so that the file112A will be transmitted (and/or retransmitted) over the network (150,159).

The estimate transmissions process 1000 begins 1020 by determining acurrent release time which is the earliest time a transmission of thefile 112A can take place. The current release time 1020 is the greaterof the transmission release date 742 specified in the acceptedtransmission request 700 and the current system time 125. The process1000 then iterates 1030 over the transmissions which need to bescheduled making a delivery criteria record 914 in the delivery criterialist 114 for each required transmission. When the process 1000 is firstcalled with a newly accepted transmission request 700, the process 1000will iterate once to create a delivery criteria record 914 for aninitial transmission of the file 112A, and then will continue toiterate, once per requested retransmission 748, to create deliverycriteria records 914 for retransmissions of the file 112A. When theprocess 1000 is called after one or more transmissions and/orretransmissions have taken place, the process 1000 iterates 1030 tomodify the remaining delivery criteria records 914, e.g. to reset therelease time (e.g. if bandwidth is freed up), and/or to adjust the size(e.g. if part of the transmission was sent and acknowledged).

The process 1000 creates and selects 1040 a delivery criteria record 914in the delivery criteria list 114 for each transmission which is to takeplace. If the process 1000 has already created a delivery criteriarecord 914 for this transmission during a prior execution, thepreviously created delivery criteria record 914 is simply selected inthe delivery criteria list 114 and not recreated. This is to avoidhaving duplicate records 914 in the delivery criteria list 114.

When the process 1000 creates 1040 a delivery criteria record 914, itsets the fields of the new delivery criteria record 914 as follows: thesize 922 field is set to the size of the file 112A; the deadline field926 is set to the transmission deadline 744 of the transmission request700; the recipients field 928 is set to the recipients 750 field of thetransmission request 700; the acknowledgments field 930 is set to theacknowledgments field 760 of the transmission request 700; the bandwidthfield 932 is set to the bandwidth constraints field 752 of thetransmission request 700; and the optional retransmissions field 934 isset to the retransmission count field 748 of the transmission request700. Further, the process 1000 sets the fields of the file list record350 contained in the delivery criteria record 914 as follows: the sourcefile identifier 310 is set to the location of the file 112A in massstorage 110; the cursor field 315 is set to indicate the start of thefile (typically set to 0); and the destination address 320 field of thefile list record 350 within the delivery criteria record 914 is set to anetwork address for the listed recipients 750.

In both cases, i.e. for new and existing delivery criteria records 914,the process 1000 continues to step 1050 where the release time 924 fieldof the selected delivery criteria record 914 is set to hold the currentrelease time 1020 value. Step 1050 also sets the recipients field 928 ofnew and existing delivery criteria records 914. In a preferredembodiment, the recipients field 928 is set to the groups of recipients750 who have not yet acknowledged receipt of the entire file 112A. Inalternate embodiments, the recipients field 928 is set to the group ofrecipients listed in the recipients field 750 in the transmissionrequest 700.

Through these two steps (1040, 1050), the process 1000 hascreated/modified a delivery criteria record 914 that will cause atransmission/retransmission of the file 112A to be scheduled by theschedule dispatch process 1100, described in FIG. 11 below, anddispatched by the dispatching process 600.

The process 1000 continues to determine 1060 the parameters for a nextretransmission of the file 112A. There are many different ways thatvalues can be selected for the fields (e.g. the release time 924, andthe deadline 926) of the delivery criteria record 914 for a nextretransmission. Steps 1070A, 1070B, and 1070C show three distinct waysof determining a next release time 924 for a next retransmission. Steps1070 A, B, and C are different preferred embodiments of the invention.In some embodiments, these steps can be user selected. One step would beselected over another by balancing ease of scheduling with networkbandwidth use and expected data loss.

Step 1070A maintains a constant release time 1020 throughout thedelivery criteria records 914. Step 1070B increments the current releasetime 1020 by the retransmission interval 746 value of the transmissionrequest. And step 1070C allots a portion of the time between the initialrelease time set in step 1020 and the deadline to eachtransmission/retransmission. This is easier to schedule but could usemore network bandwidth.

Choosing to perform step 1070A makes all delivery criteria records 914for the transmission request 700 have the same release time 924. Thismeans that the schedule dispatch process 1100 may schedule theretransmissions to take place simultaneously. And, because each deliverycriteria record 914 has the largest possible window of time between itsrelease time 924 and deadline 926 this step 1070A has the greatestlikelihood of creating feasible schedules.

Choosing to perform step. 1070B causes the release times 924 of thedelivery criteria records 914 to be staggered throughout the windowbetween the transmission release date 742 and the transmission deadline744. Each successive delivery criteria record 914 has a release time 924which is offset from the previous delivery criteria's release time 924by the retransmission interval 746. By staggering the release times 924,transmissions of a file 112A are more likely to not be broadcast overthe network 150, 159 simultaneously. And, by basing the release time1020 logic on the value of a field (i.e. the retransmission interval746), the characteristics of the system 100 can be changed by alteringthe retransmission interval 746 value. Step 1070B potentially uses lessbandwidth than step 1070A and gives flexibility in scheduling theretransmissions.

Choosing to perform step 1070C causes the release times 924 of thedelivery criteria records 914 to be evenly distributed between thewindow of the transmission release date 742 and the transmissiondeadline 744. This further lessens the likelihood of simultaneoustransmissions and tends to cause the transmissions to be dispatcheddistributed throughout the window. However, as the release time 924 of adelivery criteria record 914 nears the deadline 926 of the deliverycriteria record 914, the chances that the delivery criteria record 914may not be able to be scheduled by the dispatch schedule process 1100increase. Step 1070C potentially uses less network bandwidth than step1070A and 1070B but does not allow flexibility in scheduling theretransmissions.

Step 1070B is performed in a preferred embodiment. Alternativeembodiments may perform either steps 1070A or 1070C. Delivery criteriarecords 914A, 914B, and 914C in FIG. 9A, above, show the result ofexecuting process 1000 with step 1070B against transmission request700A, described in FIG. 7A.

Note that because the deadline 926 of the delivery criteria record 914is kept constant by each of the steps (1070A, 1070B, 1070C), the stepsall generate delivery criteria records 914 which may result insimultaneous transmissions. Further, all transmissions may be scheduledat the latest time possible by the dispatch scheduler. Alternativeembodiments may modify the deadline 926 of delivery criteria record 914in order to guarantee that a transmission is completely dispatched wellbefore its transmission deadline 744 and in time for acknowledgments tobe received and processed by the acknowledgment receiver process 135.

In another alternative embodiment, the estimate transmissions process1000 may only generate a delivery criteria record 914 for oneretransmission (rather than all retransmission count 748retransmissions). This would be done by iterating once in step 1030instead of iterating over all transmissions. In this alternativeembodiment, simultaneous transmissions of the same file 112A would notoccur because only one delivery criteria record 914 for the transmissionrequest 700 would be in the database at any one time. As the feedbackprocess 1300 indicated that the transmissions were completed, and asacknowledgments were received by process 135, successive deliverycriteria record 914 could be created for any necessary retransmissions.

Once the parameters are determined for the next delivery criteria record914, the process proceeds to step 1080 where a next iteration of step1030 takes place. Once all transmissions have been iterated 1030 over,the process ends 1090.

The scheduling processes 1100, FIG. 11, and 1200, FIG. 12, novely useEarliest Deadline First (EDF) scheduling techniques while accounting fornetwork bandwidth limitations to determine if files 112A can bedispatched 600 within the required time period subject to networking andtransmission constraints.

FIG. 11 is a flow chart of a scheduler process 1100 that convertsinformation in the delivery criteria list 114 into commands in thetransmission decision list 200 that are used by the dispatcher process600 (600A, 600B). In addition, the scheduler process 1100 determineswhether or not the delivery criteria records 914 in the deliverycriteria list 114 can be satisfied by the available system 100 resourcesto transmit files 112A over the satellite 150 and/or over the network159.

The process 1100 begins, step 1110, by accessing information in thenetwork use criteria table 500. In a preferred embodiment, theinformation in this table 500 is duplicated 1110.

The process 1100 then iterates 1115 over the delivery criteria list 114.In a preferred embodiment, step 1115 sorts the delivery criteria records914 in the delivery criteria list 114 by deadline 926, in increasingorder, earliest deadline first.

Step 1120 determines a record, e.g. by setting a pointer, in thetransmission decision list 200, and saves a prior state of the networkuse criteria table 500.

Step 1125 initializes a quantity variable to the cursor 315 identifiedin the file list record 350 of the delivery criteria record 914 selectedby the iteration step 1115.

Step 1130 performs another iteration while the quantity variable set instep 1125 is less than the size 922 of the selected delivery criteriarecord 914. While the condition in step 1130 exists, step 1200 isperformed which attempts to tentatively reserve use of the network forthe selected delivery criteria record 914 by placing time stamp 505 anddefined network use 510 information in the network use criteria table500, for the respective delivery criteria record 914. See thedescription of the FIG. 12, below.

Step 1140 determines whether or not process 1200 was able to tentativelyreserve the network use, by examining the return code (1215, 1245, 1280below).

If the return code indicates that the attempted reservation failed(1215, 1245), step 1170 rejects the selected delivery criteria record914, and optionally sends a drop signal to the delivery status 137. Thenstep 1175 changes the transmission decision list 200 to remove all theentries 250 associated with the selected record 914. In a preferredembodiment, the removed entries 250 are all those entered after thepointer set in step 1120. Further, step 1175 changes the network usecriteria table 500 to restore the network use criteria table 500 to thestate prior to the performance of step 1120.

If step 1140 determines that the network use was reserved (1280) inprocess 1200, step 1150 returns back to step 1130 where a nextreservation will be attempted for a next portion of the deliverycriteria record 914. If the quantity variable 1125 is equal to the filesize 922, step 1155 is performed and finally commits the changes in thetransmission decision list 200 and the network use criteria table 500.In a preferred embodiment, this allows the pointer in table 1120 to bemoved and the prior state information in table 500 to be overwritten. Ina preferred embodiment, these functions (transactions, rollbacks,commits) are performed by standard database techniques.

After step 1155 or step 1175 has completed, step 1180 determines ifthere is another delivery criteria record 914 to iterate over. If thereis, the process 1100 returns to step 1115. If not, the scheduler process1100 ends.

FIG. 12 is a flow chart of a novel network use allocation process 1200which tentatively reserves network use in the network use criteria table500 so that some or all of a transmission for a selected deliverycriteria record 914 can be performed. Further, the network useallocation process 1200 creates transmission criteria records 250 whichinstruct the dispatching process 600 when to begin the selected deliverycriteria record 914 transmission.

This process 1200 is executed numerous times during execution of process1100, FIG. 11 above. While process 1200 is executing, it accesses thedelivery criteria record 914 selected in step 1115, process 1100.Process 1200 accesses and modifies the network use criteria table (500,1110) which is duplicated 1110 at the start of process 1100, possiblyadding new network use criteria records 550 to the table 1110. Process1200 modifies the transmission decision list 200 by creating newtransmission criteria 250. And, process 1200 also modifies the value ofthe quantity variable 1130 maintained by process 1100.

The process 1200 begins 1205, by finding a network use criteria record550 in the network use criteria table (500, 1110) that meets thefollowing constraints: 1205 a it has a time stamp 505 which is greaterthan or equal to the release time 924 but less than the deadline 926 ofthe selected delivery criteria (914, 1115); and, 1205 b, has ampleremaining bandwidth 530 to support the bandwidth requirements 932 of theselected delivery criteria (914, 1115). In a preferred embodiment, thissearch 1205 is performed via an iteration of the network use criteriatable (500, 1110), ordered by time stamp 505. The time stamp constraint,1205 a, causes step 1205 to search for a network use criteria record 550which indicates the availability of network use during the time windowof the delivery criteria (914, 1115). Any network use criteria records550 which define network use for periods before the release time 924 orafter the deadline 926 will be ignored by the constraint 1205 a.

The bandwidth check constraint, 1205 b, causes step 1205 to search fornetwork use criteria records 550 which indicate that there is enoughbandwidth available in the network to transmit some or all of the file112A of the selected delivery criteria (914, 1115). In a preferredembodiment, the bandwidth check 1205 b consists of comparing thebandwidth requirements 932 against the remaining bandwidth 530 of thenetwork use criteria record 550. When the bandwidth requirements 932specify a bandwidth which is less than or equal to the remainingbandwidth 530, the bandwidth check constraint 1205 b is considered met.When the bandwidth requirements 932 specify a bandwidth which is greaterthan the remaining bandwidth 530, the bandwidth check constraint 1205 brejects the network use criteria record 550 as a candidate for step1205.

In a preferred embodiment step 1205 will select the network use criteriarecord 550 with the earliest time stamp 505 that meets the constraints(1205 a, 1205 b).

If no network criteria records 550 exist which meet the constraints(1205 a, 1205 b), the process, 1200 sets a failure indicator 1215 andreturns. This will cause execution of process 1100 to move to step 1170where the selected delivery criteria (914, 1115) will be dropped fromthe transmission schedule.

If a network use criteria record 550 is found, step 1210, execution ofprocess 1200 continues to (optional) step 1220. In step 1220, process1200 performs a second search of the network use criteria table (500,1110). The process 1200 searches to find the set of zero or moreadditional network use criteria records 550 which satisfy theconstraints (1205 a, 1205 b) and which are contiguous in time. That is,the process 1200 finds each record 550(a) in the network use criteriatable (500, 1110) which satisfies constraints (1205 a, 1205 b) and wherethere does not exist a second record 550(b) having a time stamp 505(b)with a value between the time stamp 505 of the found record 1205 and thetime stamp 505(a) that does not satisfy the constraints (1205 a, 1205b).

By performing these searches (1205, optionally 1220), the process 1200,locates a range of time where there is enough network use available totransmit some or all of the file 112A for the selected delivery criteria(914, 1115).

In a preferred embodiment, network use criteria records 550 can beiterated over in the network use criteria table 500, by order ofincreasing time stamp 505. This means that the searches (1205, 1220) canbe performed easily and in linear time.

After finding contiguous network use criteria records 550, executioncontinues to step 1225 where the process 1200 begins to reservebandwidth for a transmission. The process 1200 portions the first found1205 network use criteria record 550 into two new network use criteriarecords 550, 1225 a and 1225 b. The first network use criteria record1225 a holds bandwidth/network use allocated for a window of time afterthe time stamp 505 of the network use criteria record (550, 1205) butbefore the release time 924 of the selected delivery criteria record(914, 1115). The second network use criteria record 1225 b holds theremainder of the bandwidth/network use from the first found 1205 networkuse criteria record 550.

The fields of network use criteria record 1225 a are set as follows:values for the time stamp 505 and (optional) network identifier 520fields are copied from the respective fields of the first found 1205network use criteria record 550. And the aggregate 515 and definednetwork use 510 fields are set to a proportion of the aggregate 515 anddefined network use 510 fields, respectively, of network use criteriarecord 1205 equal to the proportion of the window between the releasetime 924 and the time stamp 505, compared to the network use window 525.

The fields of network use criteria record 1225 b are set as follows: thevalue of the (optional) network identifier 520 field is copied fromfirst found 1205 network use criteria record 550. The time stamp 505field is set to the release time 924 of the selected delivery criteria(914, 1115). And the aggregate 515 and defined network use 510 fieldsare set to the remaining proportion of the aggregate 515 and definednetwork use 510 fields, respectively, of network use criteria record1205 equal to the proportion of the window between the release time 924and end of the network use window 525, compared to the network usewindow 525.

After creating network use criteria record 1225 b, the process 1200removes network criteria record 1205 from the network criteria table(500, 110). And the process 1200 sets the first found network usecriteria record 1205 to be network use criteria record 1225 b.

For example, suppose that the release time 924 of the selected deliverycriteria (914, 1115) occurs five minutes after the time stamp 505 ofnetwork use criteria record 1205. And suppose that the network usewindow 525 field of the network use criteria record 1205 contains avalue of twenty minutes. Further, suppose that network use criteriarecord 1205 defines 100 units of network use 505 and has an aggregateamount of network use 510 of 60 units. Then, the release time 924 occurs¼ of time into the network use window 525. Thus, new network usecriteria record 1225 a would have a defined network use of 25 units andan aggregate amount of network use 515 of 15 units. And new network usecriteria record 1225 b would have a defined network use of 75 units andan aggregate amount of network use 515 of 45 units.

In cases where the time stamp 505 of network use criteria record 1205 isgreater than or equal to the release time 924 of the selected deliverycriteria (914, 1115), network use criteria records 1225 a and 1225 b arenot created by step 1225.

By performing step 1225, the process 1200 has now found a range ofnetwork use criteria records (the record 550 found in step 1205 andpossibly replaced by new record 1225 b, and those records 550 found instep 1220) all of which have time stamps 505 which are equal to orgreater than the release time 924 of the selected delivery criteria(914, 1115).

Process 1200 now iterates 1230 over the found network use criteriarecords 550, selecting each network use criteria record 550 ordered bytime stamp 505.

During each iteration 1230, the process 1200 computes, step 1235, aportion quantity 1235 a of data which needs to be transmitted to satisfythe selected delivery criteria (914, 1115). This portion quantity 1235 ais equal to the value in the size 922 field of the selected deliverycriteria record (914, 1115) less the amount in the quantity variable1130 of process 1100. The process 1200 then determines a computedbandwidth rate 1235 b suitable for the selected network criteria 550 anddivides the portion quantity 1235 a by the computed bandwidth rate 1235b to compute a duration value 1235 c.

Step 1235 is a time to transmit process which determines the time totransmit a portion of a file 112A within the constraints of the deliverycriteria record 914, transmission criteria 770, and available networkuse 550. In alternative embodiments, these transmission criteria 770 canfurther include the time of day and/or size of network buffers (124A,124B).

In a preferred embodiment, the computed bandwidth rate 1235 b is set tothe bandwidth 932 specified in the selected delivery criteria record(914, 1115). In alternate embodiments, the computed bandwidth rate 1235b may vary if the bandwidth 932 specifies a range of allowable bandwidthvalues. In these alternate embodiments, the computed bandwidth rate 1235b may be set to a preferred bandwidth value which is specified 932 inthe selected delivery criteria record (914, 1115) and which there isspace for (remaining bandwidth 530) in the selected network use criteriarecord 1230.

If the computed duration value 1235 c is greater than the window betweenthe time stamp 505 of the selected network use record 1230 and the nextnetwork use record 550, step 1235 adjusts the computed duration value1235 c to be equal to the window. And step 1235 adjusts the portionquantity 1235 a to be equal to the amount of data which can be writtenin that window, e.g. the computed bandwidth rate 1235 b multiplied bythe new computed duration value 1235 c.

The process 1200, step 1240, then compares the computed duration value1235 c against the deadline 926 in the selected delivery criteria record(914, 1115). When the value of the time stamp 505 of the selectednetwork use criteria record 1230 plus the computed duration value 1235 cis greater than the deadline 926, execution of the process 1200 moves tostep 1245 where the process sets a failure indicator, ends itsexecution, and returns to process 1100. In this case, the process 1200,step 1245, has determined that there is not enough time and bandwidthavailable between the time stamp 505 and the deadline 926 to completethe transmission of the file 112A and, hence, a failure code isreturned.

When the process 1200 determines that there is enough time and bandwidthto transmit a portion 1235 a of the file 112A before the deadline,execution moves to step 1250. The process, step 1250, compares thecomputed duration value 1235 c to the network use window 525. If thecomputed duration value 1235 c holds a time interval smaller than thenetwork use window 525, step 1255 portions the selected network usecriteria record 1230 into two new network use criteria records 1255 aand 1255 b.

New network use criteria record 1255 a represents the network use duringthe time period starting at the time stamp 505 of network use criteriarecord 1230 and extending to the time interval of the computed duration1235 c. Network use criteria record 1255 b represents the network usefor the remainder of the time at and past the duration 1235 c up to thenetwork use window 525.

The fields of network use criteria record 1255 a are set as follows:values for the time stamp 505 and (optional) network identifier 520fields are copied from the respective fields of the selected network usecriteria record 1230. And the aggregate amount of network use 515 anddefined network use 510 fields are set to a proportion of the aggregateamount of network use 515 and defined network use 510 fields,respectively, of network use criteria record 1230 equal to theproportion of the window between the duration 1235 c and the network usewindow 525 of the selected network use criteria record 1230.

The fields of network use criteria record 1255 b are set as follows: thevalue of the (optional) network identifier 520 field is copied fromfirst found 1205 network use criteria record 550. The time stamp 505field is set to the value of the time stamp 505 of the selected networkuse criteria record 1230 plus the duration 1235 c. And the aggregateamount of network use 515 and defined network use 510 fields are set tothe remaining proportion of the aggregate amount of network use 515 anddefined network use 510 fields, respectively, of network use criteriarecord 1230 equal to the proportion of the time between the duration1235 c and the network use window 525.

After creating network use criteria records 1255 a and 1255 b, theprocess 1200 removes network criteria record 1230 from the networkcriteria table (500, 1110). And the process 1200 sets the selectednetwork use criteria record 1230 to be network use criteria record 1255a.

Execution of the process 1200 then continues to step 1260. Step 1260will also be executed (and step 1255 bypassed) when step 1250 finds thatthe computed duration 1235 c is equal to the network use window 525.

Step 1260 creates a new transmission criteria 250 record for thetransmission criteria table 200. This transmission criteria 250 recordinstructs the dispatching process 600 to send a portion of the file 112Afor the selected delivery criteria (914, 1115). The fields of the newtransmission criteria 250 are set as follows: the index 205 is set tothe index 305 of the file list record 350 in the selected deliverycriteria record 914; the release time 210 is set to the time stamp 505of the selected network use criteria record 1230; the quantitycompletion measure 235 is initialized (set to zero in a preferredembodiment); and the status code 240 is set to a “Pending” value.

In a preferred embodiment, step 1260 sets the burst size 225 and burstrate 230 fields to values for the computed bandwidth rate 1235 bdetermined in step 1235. The portion quantity field 215 is set to thecomputed portion quantity 1235 a, and the duration field 220 is set tothe computed duration 1235 c. In alternate embodiments, the durationfield 220 may be left unspecified, set to the value of the deadline 926in the selected delivery criteria record (914, 1115), or set to thevalue of the time stamp 505 in the next network use criteria record 550.

Step 1260 has now created a new transmission criteria 250 recordrequesting that the dispatching process 600 transmit a portion of thefile 112A for the selected delivery criteria record (914, 1115).Execution of process 1200 moves to step 1265 where 1265 a the value ofthe computed portion quantity 1235 a is added to value stored in theaggregate amount of network use field 515 for the selected network usecriteria record 1230. This records that network use has been reservedfor the new transmission criteria 250 record. Process 1200 further 1265b adds the computed portion quantity 1235 a to the quantity variable1125 of process 1100. Thus quantity variable 1125 is updated to hold theamount of data which has been scheduled for the currently selecteddelivery criteria (914, 1115).

Step 1270 compares the quantity variable 1125 to the value of the size922 field in the selected delivery criteria record (914, 1115). If thequantity 1125 is not equal to the size 922, more transmission criteria250 records need to be created to satisfy the delivery criteria (914,1115). The process 1200 continues execution to step 1275 where, if thereare more found network use criteria records 1230, execution branchesback to step 1230.

When the quantity 1125 is equal to the size 922 (step 1256), or whenthere are no more network use criteria records 1230 to iterate over (asdetermined by step 1275), execution continues to step 1280 where theprocess 1200 sets a success indicator value and execution of process1200 ends.

Note that the constraints (1205 a, 1205 b) chosen for steps 1205 and1220 determine the range of time during which a portion of a deliverycriteria record 914 may be transmitted. Constraints 1205 a, 1205 b havebeen chosen to match the characteristics of the dispatching process(600A, 600B) used in a preferred embodiment of this invention.

Alternative embodiments may use alternate processes, such as the FazztDigital Delivery System by KenCast, Inc. to perform the function of thedispatching process (600A, 600B). New constraints in addition to, or inreplacement for, constraints 1205 a and 1205 b may be added to thenetwork use allocation process 1200. For instance, if the alternatedispatching process 600 has a limitation on the number of simultaneousportions of files 112A which may be transmitted at any given time, aconstraint 1205 c may be introduced to process 1200 which enforces thislimit. A constraint 1205 c may check that no more than four transmissioncriteria records 250 exist with release times 210 and durations 220 thatoverlap the network use window of a candidate (1205, 1220) network usecriteria record 550 This alternate constraint 1205 c would cause thenetwork use allocation process 1200 to not schedule any more thanoverlapping simultaneous transmission criteria records 250.

Another alternate constraint 1205 d could be put in place to check thatthere was enough remaining network bandwidth in contiguous network usecriteria records 500 so that it was possible to schedule the file 112Afor transmission as one portion.

Further, an alternate constraint 1205 e could be put in place to limitthe cumulative bandwidth delivered to a destination or destination groupduring a time period. Alternate constraint 1205 e could check, forexample that no more than a cumulative 10 Mbps was transmitted for adestination, regardless of the number of simultaneous transmissionsdelivered to the destination.

Process 1100 iterates over the delivery criteria list 114, step 1115,ordered by deadline 926, and the delivery criteria record 914 which havethe earliest deadlines 926 are scheduled first. Process 1100 and 1200use the network use criteria table 500 to schedule based on bandwidth aswell as time. Constraint 1205 b of process 1200 allows multipletransmissions of portions of files 112A to be scheduled simultaneouslyduring the same time period therefore allowing overlapping andsimultaneous scheduling. Step 1265 a of process 1200 works withconstraint 1205 b to keep track of the bandwidth consumed bysimultaneously scheduled transmissions so that the cumulative bandwidthscheduled during a time period is not greater than the availablebandwidth for the time period.

Further, by allowing multiple network use criteria records 550 to exist,each with a distinct network use window 525, processes 1100 and 1200 cancreate schedules which are designed for networks (150, 159) with nonconstant bandwidth availability. As discussed in FIG. 5 above, differingportions of bandwidth may be available to a network during differenttimes of day. For instance, 45 Mbps of network bandwidth may beavailable during off-peak hours but only 15 Mbps available during peaktime.

A preferred embodiment of this invention creates a transmission decisionlist 200 using processes 1100 and 1200. Alternate embodiments may useother scheduling algorithms such as more complicated EDF algorithms,e.g. the Robust Earl-lest Deadline (RED) algorithm, or algorithms whichschedule by other means, e.g. Rate Monotonic (RM) algorithms. Thesealgorithms may be amended to contain constraints similar to 1205 b tocheck for available bandwidth, and to record aggregate amounts ofnetwork use as done in step 1265 a. EDF algorithmns are discussed in thebook Deadline Scheduling For Real-Time Systems, EDF and RelatedAlgorithms by John A Stankovic, Marco Spuri, Krithi Ramamritham, GiorgioC. Buttazzo Copyright 1998 by Kluwer Academic Publishers, ISBN0-7923-8269-2, which is herein incorporated by reference in itsentirety.

FIG. 13 is a flow chart of an optional feedback process 1300 whichexamines entries in the file transmission history log 400 and adjustsrelated transmission requests 700 accordingly.

The process 1300 begins, step 1310, by iterating 1320 over the entriesin the history log 400. The history log 400 is populated by thedispatching process 600 (600A, 600B) whenever a portion of a file 112Ais transmitted over the network (150, 159). In a preferred embodiment,the process 1300 iterates over history records 450 which have been addedto the history log 400 after a previous execution of process 1300. Bydoing this, history records 450 are not examined twice. The process 1300can detect newly added history records 450 by examining the value in thecompletion time stamp 420 field.

Step 1325 locates the transmission request 700 associated with thehistory record 450. The transmission request 700 can be found throughthe index 405 field of the history record 450. The index 405 fieldidentifies the file list record 350 and thus identifies the file 112Awhich has an association with the transmission request 700. Throughsimilar steps of following indirection, the process 1300 can locate thedelivery criteria record 914 which contains the file list record 350associated with the history log 450.

The process 1300 then, step 1330, examines the status code 415 field ofeach history record 450 selected in step 1320. The status code 415 fieldcontains information regarding an attempted transmission of a portion ofa file 112A over the network (150, 159). In a preferred embodiment, thestatus code 415 is checked to see if it contains one of two values. Whenthe status code 415 contains a “File not found” indicator, the dispatchprocess 600 attempted to make a transmission but found that the file112A did not exist in the memory/mass storage 110. In this case, theprocess moves to step 1340. When the status code 415 contains a“Success” indicator, the dispatch process 600 successfully transmitted aportion of a file 112A over the network (150, 159). In this case, theprocess moves to step 1370. In alternate embodiments, the status code415 is checked to see if it contains additional values such as a“Preempted due to network error” or “Preempted due to disk error” andappropriate steps are performed for each of these indicators.

When a file 112A was not found by the dispatch process 600, execution ofthe process 1300 moves to step 1340. Step 1340 increases thetransmission release time 742 of the found transmission request (700,1325). In a preferred embodiment, the transmission release time 742 isincreased by a fixed value, e.g. an hour. In alternate embodiments, thetransmission release time 742 may be increased by a value related to theexpected data file size 722.

The transmission release time 742 is increased because the data for thefile 112A has not yet been completely retrieved from the client 180 byretrieval function 843. Increasing the transmission release time 742allows the retrieval function 843 to have more of an opportunity toreceive the data file 112A.

Note that as the transmission release time 742 is increased and movescloser to the transmission deadline 744, it is more likely that aschedule cannot be created by the schedule process 800 which willsatisfy the transmission criteria 770 with available network use 500. Byincreasing the transmission release time 742, the feedback process 1300may cause the transmission request 700 to be dropped 882 by the scheduledispatch process 1100. In an extreme case, the transmission release time742 may be increased past the transmission deadline 744, andtransmission request 700 will be dropped 882.

Alternate embodiments of process 1300 may perform an acceptance test 139to determine if the modified transmission criteria 770 is stillacceptable within the system 100.

In further alternate embodiments, the process 1300 drops thetransmission request 700 when the file 112A has not been retrievedbefore the transmission release time 742. This rejection can cause anotification signal, e.g. an e-mail message, to be transmitted to theclient 180, informing the client 180 of the dropped request 700, andcause the client 180 to schedule a next transmission of the file 112A byinteracting with the request receiver process 144.

After increasing the release time, step 1340, executon of process 1300moves to step 1380 where, if a next history log record 450 exists, it isselected for iteration and execution branches to step 1320. After allhistory log records 450 have been iterated 1320 over, execution branchesto step 1390 where the process 1300 ends.

When step 1330 finds that the status code 415 contains a “Success”indicator, execution of process 1300 moves to step 1370. Step 1370examines fields in the file list record 350 and the delivery criteriarecord 914 associated with the selected history record 450 to determineif a file 112A has been completely transmitted. If the cursor 315 fieldof the file list record 350 is equal to the size 922 field of tidedelivery criteria record, all portions of the file 112A have beentransmitted, and execution of process 1300 proceeds to step 1375. In apreferred embodiment, step 1375 sends a message to the client 180indicating that a transmission/retransmission of the file 112A hascompleted. In alternate embodiments, the process 1300, step 1375, mayalso send messages to the recipients 928 listed in the delivery criteriarecord 914. This message would request acknowledgment of the transmittedfile 112A and may be sent conditionally based on the value of theacknowledgments 930 field. After performing step 1375, execution of theprocess 1300 continues to step 1380.

Step 1375 may optionally produce a bill after each successfultransmission, may create a new line items in a pending bill whichcharged an amount for each transmission, or may send a signal to abilling process 136 to perform the billing. The billing process 136could examine the history log 400 to determine how many portions of afile 112A were sent for a transmission request and generate a billaccordingly.

When the process 1300 determines that a file 112A has not yet beencompletely transmitted 1370, execution of the process branches directlyto step 1380 where the process 1300 will perform a next iteration 1320of a next history record 450, or end 1390 when all history records 450have been iterated through.

In a preferred embodiment, process 1300 is executed by the scheduleprocess (128, 134) on a periodic basis, e.g. every five minutes. Inalternate embodiments, process 1300 is executed whenever new historyrecords 450 are added to the history log 400, or when a the number ofnew history records 450 within the history log 400 passes a threshold,e.g. when there are at least twenty new history records 450 in thehistory log 400.

In addition to writing history records 450 into the history log 400r),the dispatching process 600 generates other information which may beused for feedback. As the dispatching process 600 transmits portions offiles 112A over the network (150, 159), it modifies the aggregate amountof network use 515 fields of network use criteria records 550. Thesemodified network use criteria records 550 are used by the scheduledispatch process 1100, FIG. 11 above, to determine the remainingbandwidth 530 during a time period.

The dispatching process 600 also updates the cursor field 315 of filelist records 350 as it transmits portions of their associated files112A. The cursor field 315 is used by process 1100, step 1125, andprocess 120), step 1235, to determine the quantity of file 12A datawhich needs to be transmitted. As portions of the file 112A aretransmitted over time for distinct delivery criteria records 914, thecursor field 315 of the delivery criteria records 914 is increased. And,if the schedule dispatch process 1100 is executed after a portion of afile 112A has been transmitted, because the cursor 315 field will havebeen updated during the portion transmission, the schedule dispatchprocess 1100 will not try to reschedule that portion.

Referring back to the description of FIG. 8, box 135 is an optionalacknowledgment receiver process. This process 135 receives messages(e.g. positive or negative acknowledgments) from clients (160, 170) thatindicate successful receipt of a transmission, successful receipt of oneor more portions of a transmission; partial receipt of a transmission,and receipt of a transmission with errors (e.g. missing data, damageddata, partial data) in one or more of its portions. Upon receivingacknowledgments (positive or negative), the process 135 examines theassociated transmission request 700 and determines if a retransmissionof the data file 112A or a portion of the data file 112A is warranted.When the process 135 determines that a retransmission is needed or is nolonger needed, it signals the estimate transmissions process 1000 toschedule and/or remove delivery criteria 914 associated with thetransmission request 700. The process 135 may also signal the billingprocess 136 to generate a bill.

FIG. 14 is a flow chart of an acceptance process 139 which determines ifit is possible to schedule a transmission of the information in thetransmission request 700 in accordance to the received transmissionconstraints 770.

The acceptance process 139 begins, step 1410, by iterating over thetransmission constraints 770 in the transmission request 700 received bythe request receiver process 144. In a preferred embodiment of theinvention, the transmission request 700 contains only one transmissionconstraint 770. However, in alternate embodiments, the transmissionrequest 700 may contain multiple transmission constraints 770, and eachis iterated over in turn by step 1410.

Step 1420 of the process 139 estimates the cost of performing thetransmission request 700 in accordance to the selected transmissionconstraints (770, 1410). The costs of the transmission can be based onmany cost factors and fees. Cost factors which relate to the contentgenerator process 146 include: rental of a network connection 157 (aleaded line, an internet connection) between the client 180 and theserver 140; an on-line; or off-line storage fee to maintain theretrieved files 112A in mass storage 110; a fee relating to the expecteddata file size 722 of the file 12A being retrieved; a fee relating tothe expected length of time taken to retrieve the data file 112A; a feefor preparation work (digitization, encryption) requested by packagingoptions 720; and a fee for polling the client 180 to retrieve updateddata files 112A.

Cost factors which relate to the transmissions of the data file 112Ainclude: a priority based fee; network usage fees based on peak andoff-peak transmission release times 742 and transmission deadlines 744;fees based on the amount of leeway between the transmission release time742 and the transmission deadline 744; number of retransmissionsrequested (retransmission count 748); and the acknowledgments 760requested. The cost may also be influenced by the number of recipients750 which are to acknowledge the transmissions, and their priorreception history. A client 180 may qualify for a discount if all therecipients 750 in a transmission request 770 have a history of excellentreception and retransmissions 748 are not expected to be necessary. Afurther cost factor may be the type of report offered to the client 180detailing the transmissions, retransmissions, and itemized success orfailure of recipient 750 reception. Other factors which are consideredby the billing process 136 may also be estimated by step 1420.

After calculating an estimate of the cost of the transmission, step1420, the process 139 checks, step 1430, to see if the cost is withinthe (optional) biiling cost 734 amount specified in the transmissionrequest 700. If the estimated cost 1420 is greater than the billing cost734, execution of the process 139 branches to step 1460 where aniteration of a next transmission constraint 770 is performed.

If the estimated cost 1420 is equal to or less than the billing cost 734(or if the optional billing cost field 734 was omitted), the process 139tests the transmission request 700 for, step 1435, other businessconstraints. For instance, the process 139 may estimate the timerequired to perform transformations requested in the packaging optionsfield 720 such as encryption or digitization. The transmission request700 is then checked to see that there is a sufficient amount of timebetween the retrieval start time 714 and the transmission release time742 to prepare the file 112A for transmission. The process 139 may alsostep 1435, estimate the time required for the content generator process146 to retrieve the data file 112A, given its estimated data file size722, and see that there is enough time to retrieve the data file 112Abefore transmitting it.

In alternate embodiments, the tests of step 1435 are performed beforestep 1430.

If the transmission request 700 passes the tests of step 1435, theprocess 139 executes process 1000 to estimate the transmissions whichare required to fulfill the transmission constraints 770. The process139 then executes process 1100 to schedule the transmission. Whenexecution of process 1100 ends with the transmission being successfullyscheduled, i.e. it was not dropped (882 and step 1440), the transmissionconstraint 770 are considered acceptable to the system 100 and thetransmission request 700 is accepted, step 1450.

If during execution of process 1100, the transmission is dropped (882and step 1440), the acceptance process 139 determines that thetransmission constraint 770 cannot be scheduled by the system 100.Execution of the process 139 moves to step 1460 where an iteration of anext transmission constraint 770 is performed.

Step 1460 checks the transmission request 700 to see if it contains anytransmission constraints 770 which have not yet been iterated over. Ifso, step 1460 causes execution of the process 139 to branch to step 1410to perform the next iteration. When all transmission constraints 770have been iterated over 1410, execution of the process 139 moves to step1470 where the transmission request 700 is rejected. All candidatetransmission constraints 770 have been examined and none have foundacceptable, so the transmission request 700 is rejected and a rejectionsignal is sent to the client 180 by the request receiver process 144.The client 180 can then submit a new transmission request 700 withalternate transmission constraints 770.

In alternate embodiments, the acceptance process 139 marks eachtransmission constraint 770 with an indication of why it was consideredunacceptable. This marking can indicate that a constraint 770 was toocostly and not accepted by step 1430, for example. Or the marking canindicate that the cost was sufficient but there was not enough availablenetwork use, determined by step 1440, to schedule the transmissionrequest 700. The marked up transmission constraints 770 are returned tothe client 180 by the request receiver process 144 and provide theclient 180 with information which can be used to negotiate an acceptabletransmission request 700.

Alternate embodiments may also return a copy (or a detailed orsummarized report) of the network use criteria table (500, 1110) used inthe schedule dispatch process 1100, when transmission requests 700 arerejected. This report would let the client 180 know when the network hasavailable bandwidth and would let the client 180 fine-tune a nexttransmission request 700 that would be more acceptable.

Further embodiments of the acceptance process 139 may execute processes1000 and 1100 for transmissions to be performed in the near-term only(e.g. within one week), and perform an alternate acceptance test forlong-term transmissions. This alternate test would be used to roughlyforecast the network bandwidth availability.

In a non limiting example, a subscriber, such as a software provider(client 180), wants to provide software updates to its network (150,159) connected customers (160, 170). The software provider sends atransmission request 700 to the request receiver process 144. The file112A containing the software updates is 100 megabytes long. Theconnected customers (e.g. recipients 750) can receive at speeds up to128 kilobits per second (e.g. bandwidth constraints 752). The softwareprovider requests (through packaging options field 720) that thesoftware updates be encrypted and digitally signed. The softwareprovider also requests (through acknowledgments field 760) that eachrecipient 750 acknowledge receipt of the file 112A. The softwareprovider specifies a retrieval start time 714 of 08.00 AM, atransmission release time 742 of 08:30 AM, and a transmission deadline744 of 09:00 AM.

The request receiver process 144 receives the software provider'stransmission request 700 and passes it to the acceptance process 139.The acceptance process 139 rejects the transmission request 700 becausethe content generator process 146 requires at least forty-five minutesto retrieve the data file 112A, encrypt it, and sign it (rejection dueto failure of tests in step 1435); and because (rejection due to failurein step 1440) the 100 megabyte file 112A cannot be transmitted in thirtyminutes at 128 kilobits per second.

After the transmission request 700 is rejected by acceptance process139, the request receiver notifies the software provider (client 180) ofthe rejection and indicates the minimal time requirements needed tosatisfy the tests of step 1435 and 1440. A person at the softwareprovider submits a second transmission request 700 with a transmissionrelease time 742 of 11:00 AM and a transmission deadline 744 of 02:30PM. This second transmission request 700 is accepted by process 139.

Referring now to FIG. 8, an additional action taken 888 is for thedelivery status module 137 to notify the acceptance process 1440 when adelivery criteria record 914 associated with a candidate transmissionconstraint (1410, 770) was dropped.

Alternate embodiments of the system architecture 800 may includemultiple scheduler processes (128, 134), request receiver processes 144and acceptance processes 139, content generators 146, dispatch processes600 (600A, 600B), acknowledgment receiver processes 135, and deliverystatus modules 137, communicating with each other. One request receiverprocess 144 may act as a broker and forward a received transmissionrequest 700 to multiple acceptance processes 139 in an attempt to have atransmission request 700 accepted at a preferred billing rate ortransmission criteria 770. If a first acceptance process 131 rejects thetransmission request 700, the request 700 would be passed by the requestreceiver broker 144 to a second acceptance process 139 which may beconnected to a system 100 which offers better rates or have moreavailable bandwidth.

A broker request receiver process 144 may also break a transmissionrequest 700 into two or more new transmission requests 700 which may beaccepted, rejected, and/or serviced independently. For example, supposea company wishes to deliver a digitized video of a product announcementto people who have registered on its mailing list. The recipients forthe product announcement may include satellite connected users (e.g.160), terrestrial users (e.g. 170) connected to the Internet MulticastBackbone (M-Bone), and terrestrial users (e.g. 170) connected to theInternet via America On-Line (AOL). The company may create atransmission request 700 which lists all of its users and send therequest 700 to a broker request receiver process 144. This brokerrequest receiver process 144 may generate three transmission requests700, the request 700 listing the satellite connected users, the M-Boneconnected terrestrial users, and the AOL users, in the recipients 750field, respectively. The broker request receiver process 144 would thensubmit the new transmission requests 700 to acceptance processes 139which were connected to the appropriate networks (150, 159).

A broker request receiver process 144 may also break a transmissionrequest 700 into two or more new transmission requests 700 by othermeans (besides recipient 750 network 150,159 connectivity). Forinstance, a broker request receiver process 144 which receives atransmission request 700 asking for a retransmission 748 may generatetwo transmission requests 700, each asking for zero retransmissions 748.In essence, the broker request receiver process 144 performs anegotiation process with one or more acceptance processes 139 on behalfof a client 180.

Other businesses processes may also be built around the system 100. Acompany may wish to have data files on its agent computers synchronizedwith a central data source. Each time a file 112A changes at the centraldata source (client 180), a transmission request 700 could be generatedto have the new data file 112A transmitted over the network (150, 159)to the company's agents (160, 170). This file 112A may or may not beencrypted to maintain privacy.

Another company may add a finishing process to the system 100 whichreceives a transmitted data file 112A and forwards it on a local areanetwork to other network connected clients or performs some other finalmanipulation. A sample finishing process may be for received data files112A at a client (160, 170) which contain e-mail messages to beforwarded over a local area network. Or, when received data files 112Acontain digitized video, the finishing process maybe to convert thefiles 112A into analog NTSC video for displayed in an auditorium orconference room, or storage on analog video tape.

The system 100 makes it easy to transmit data files 112A to a largenumber of recipients and provides an assurance that the transmissionwill take place. And, it provides a way to manage the network (e.g.Satellite network) bandwidth. This easy-to-use system opens thesatellite marketplace up to many new business opportunities. Small tomidsize businesses can now transmit their digital information over thesatellite easily and economically.

Note that a business method using the present invention is furtherdescribed and claimed in U.S. patent application Ser. No. 09/649,973,still pending, entitled “A Method of Doing Business over a Network byTransmission and Retransmission of Digital Information on a NetworkDuring Time Slots” to Vogl, et al. which was filed on the same day asthe parent application to the present application, and which is hereinincorporated by reference in its entirety as if fully restated herein.

Given this disclosure alternative equivalent embodiments will becomeapparent to those skilled in the art. These embodiments are also withinthe contemplation of the inventors.

1. A computer system for delivering digital information over a network,the computer system having one or more memories, one or more centralprocessing units, and one or more network connections, the systemfurther comprising: a request receiving process configured to receive arequest for transmitting digital information, the request specifying aplurality of constraints comprising at least a delivery time constraintand a cost of delivery constraint, the digital information having anumber of packets; a transmit time process configured to determine thetime required to transmit the digital information based on the number ofpackets and a network speed; a scheduler configured to schedule atransmit time for the digital information; and an acceptance processconfigured to accept the digital information for transmission only ifthe plurality of transmission constraints are satisfied, the acceptanceprocess further comprising a transmission cost estimation processconfigured to estimate the cost of transmitting the digital informationin accordance with the plurality of constraints.
 2. A system, as inclaim 1, where the digital information is transmitted at a first price.3. A system, as in claim 1, where the digital information is rejectedfor transmission if the delivery time constraints cannot be satisfied.4. A system, as in claim 3, where the scheduler reschedules a transmittime after the digital information is rejected.
 5. A system, as in claim3, where the digital information is accepted for transmission at asecond price.
 6. A system, as in claim 3, where the digital informationis rescheduled by the scheduler and accepted for transmission at asecond price after the information is rejected.
 7. A system, as in claim1, where the time required to transmit is dependent on any one or moreof the following: network speed, time of day, and size of buffer.
 8. Asystem, as in claim 1, where the digital information is accepted fortransmission and is transmitted.
 9. A system, as in claim 8, thatreceives an acknowledgement of the transmission.
 10. A system, as inclaim 9, that produces a bill on receipt of the acknowledgement.
 11. Asystem, as in claim 1, where one or more portions of the digitalinformation are accepted for transmission and are transmitted.
 12. Asystem, as in claim 11, that receives an acknowledgement of thetransmission of one or more of the portions.
 13. A system, as in claim12, that produces a bill on receipt of the acknowledgement for one ormore of the portions.
 14. A system, as in claim 1, where the digitalinformation is accepted for transmission and is transmitted but anegative acknowledgment is received.
 15. A system, as in claim 14, wherea negative acknowledgment is any one or more of the following: a missingdata, a damaged data, a partial data.
 16. A system, as in claim 1, wherethe digital information is accessed at a time after the acceptanceprocess accepts the digital information but before the scheduledtransmit time.
 17. A method for delivering digital information over anetwork comprising: receiving a request for transmitting digitalinformation having a number of packets, the request specifying aplurality of constraints comprising at least a delivery time constraintand a cost of delivery constraint; determining the time required totransmit the digital information based on the number of packets and anetwork speed; scheduling a transmit time for the digital information;estimating cost of transmission in dependence on the plurality ofconstraints; and accepting the digital information for transmission onlyif the plurality of constraints can be satisfied.
 18. A computer systemfor delivering digital information over a network comprising: means forreceiving a request for transmitting digital information having a numberof packets, the request specifying a plurality of constraints comprisingat least a delivery time constraint and a cost of delivery constraint;means for determining the time required to transmit the digitalinformation based on the number of packets and a network speed; meansfor scheduling a transmit time for the digital information; means forestimating cost of transmitting the digital information in accordancewith the plurality of constraints; and means for accepting the digitalinformation for transmission only if the plurality of constraints can besatisfied.
 19. A computer program product for delivering digitalinformation over a network having a program comprising the followingsteps: receiving a request for transmitting digital information having anumber of packets, the request specifying a plurality of constraintscomprising at least a delivery time constraint and cost of deliveryconstraint; determining the time required to transmit the digitalinformation based on the number of packets and a network speed;scheduling a transmit time for the digital information; estimating costof transmission in accordance with the plurality of constraints; andaccepting the digital information for transmission only if the pluralityof constraints can be satisfied.
 20. A computer system as in claim 1,wherein the plurality of constraints further comprises an electronicpackaging constraint indicating how the digital information should beelectronically packaged.
 21. A computer system as in claim 20, whereinthe electronic packaging constraint concerns encryption of the digitalinformation.
 22. A computer system as in claim 20, wherein theelectronic packaging constraint concerns generation of forward errorcorrection codes for the digital information.
 23. A computer system asin claim 20, wherein the electronic packaging constraint concernscompression of the digital information.
 24. A computer system as inclaim 20, where the acceptance process is further configured to acceptthe digital information for transmission if transformations required bythe electronic packaging constraint can be performed while stillsatisfying the delivery time constraint.
 25. A computer system as inclaim 20, where the acceptance process is further configured to acceptthe digital information for transmission if transformations required bythe electronic packaging constraint can be performed while stillsatisfying the cost of delivery constraint.
 26. A computer system fordelivering digital information over a network, the computer systemcomprising at least one memory, at least one central processing unit,and at least one network connection, the system further comprising: arequest receiving process configured to receive a request fortransmitting digital information, the request specifying a plurality ofconstraints comprising at least a delivery time constraint and a cost ofdelivery constraint; a transmit time process configured to determine thetime required to transmit the digital information based on the number ofpackets and a network speed; a scheduler configured to schedule atransmit time for the digital information; a plurality of acceptanceprocesses each configured to accept the digital information fortransmission only if the plurality of transmission constraints aresatisfied and to forward a message indicting that the digitalinformation cannot be accepted if the plurality of transmissionconstraints cannot be satisfied, each of the plurality of acceptanceprocesses further comprising a transmission cost estimation processconfigured to estimate the cost of transmitting the digital informationin accordance with the plurality of constraints; and a broker processconfigured to receive a message from at least one of the plurality ofacceptance processes indicating that the at least one of the pluralityof acceptance processes cannot transmit the digital information inaccordance with the plurality of transmission constraints, the brokerprocess further configured to forward the digital information to anotherone of the plurality of acceptance processes upon receipt of the messagefrom the at least one of the plurality of acceptance processes.
 27. Acomputer system for delivering digital information over a network, thecomputer system having one or more memories, one or more centralprocessing units, and one or more network connections, the systemfurther comprising: a request receiving process configured to receive arequest from a client for transmitting digital information, the requestspecifying a plurality of transmission constraints comprising at least adelivery time constraint and a cost of delivery constraint, the digitalinformation having a number of packets; a transmit time processconfigured to determine the time required to transmit the digitalinformation based on the number of packets and a network speed; ascheduler configured to schedule a transmit time for the digitalinformation; an acceptance process configured to accept the digitalinformation for transmission only if the plurality of transmissionconstraints are satisfied, the acceptance process further comprising atransmission cost estimation process configured to estimate the cost oftransmitting the digital information in accordance with the plurality ofconstraints; and the request receiving process further comprising anegotiating process for facilitating negotiations between the acceptanceprocess and a client submitting the request, and wherein the acceptanceprocess is configured to negotiate with the client to reach acceptabletransmission constraints, the acceptance process accepting the digitalinformation for transmission only if acceptable transmission constraintsare negotiated.